6 ms·

It is a bit weird to frame one of two competing protocols as the successor of the other, when the only data point for this assertion is that one is older.

tcfhgj 3y ago
Matrix basically solves problems of XMPP: - resilience against servers going down - resilience against malicious federation - Json instead of XML - unified specification - handling of E2EE with multiple devices and message history - not need to rely on other servers for media access Probably more, this was just off the top of my head
- toastal 3y ago
  Matrix has its de facto centralized server in Matrix.org where almost all rooms will have its data sent through because of accounts joining rooms. The servers have been too heavy/expensive for self-hosting that many end up relying on the big servers to use (maybe the Rust server will help, Dendrite?), but the “resilience” mentioned is a big cause for this expense (similar issues with Mastodon). JSON isn’t superior to XML--it can be in some cases but it’s not without drawbacks; experimental EXI could help with the size. XEPs are an ad hoc unified spec, and the buy-into-or-not nature has some advantages where it’s easier to experiment and fallbacks are common even with fragmentation. OMEMO isn’t perfect, but it does cover multi-device encryption and carbons work to get message history. I like Matrix. But I don’t think it’s the only or best solution despite all of the current hype; the XMPP solution should be looked at more often. XMPP offers additional flexibility as well not being limited to just a chat/communications platform where folks use it for presence, UnifiedPush, etc.
  - panick21_ 3y ago
    Its not to big to self host. It uses maybe a bit to much memory but anybody that has a real server (more then a Pi) can host it mostly fine. And many do. Most federated system have one large server that has many users.
    - toastal 3y ago
      I hosted an ejabbard server on a 2014 smart phone for a while earlier this year. ejabbard & Prosody are reasonable to host using DDNS on a home network on just about any hardware which is much more accessible and decentralized than needing a “real server”.
  - wkat4242 3y ago
    There's many servers on matrix and even synapse isn't that heavy. What bothers me the most about xmpp is that only the barebones stuff is in the main spec and everything else is in extensions which creates a complex maze of support by servers and clients alike. I've used both but I like matrix the most. Its bridges also seem the most mature.
    - toastal 3y ago
      Being barebones is a part of the selling point for an eXtensible platform though. ejabberd came with really good defaults, and Prosody only a little painful (though most of that could be chalked up to DNS being a pain + Nginx behaving unexpectedly). If you need something more turnkey, Snikkit can be useful if you believe Docker is a good idea.
      - wkat4242 3y ago
        > Being barebones is a part of the selling point for an eXtensible platform though. Understood but as a user I don't want core functionality like history to be hidden behind extensions which may or may not be supported or need additional components to client or server. As a user (and home server operator) I found that Matrix+Element gives me a much better user experience with much less fuss (though I admit it was more than 5 years ago when I last ran ejabberd). And the bridges are amazing, just what I needed. Because Matrix is not very useful until everyone uses it, for the transition there are bridges. I don't really care about the underlying architecture, I just want it to easily provide me a modern chat experience.
        toastal 3y ago
        > core functionality like history I won’t disagree with this. It could be a part of the main spec, but there’s some novelty knowing you could do a ‘complete’ server or client in a day. There are certainly different modern expectations than compared to IRC. Compared to the OP, barebones XMPP is much closer to a ‘simple chat’. > bridges XMPP + libpurple were trying to do similar things. For a hot minute everyone, even the like of Facebook Chat and whatever Google’s chat was named at the time, was using XMPP til they all decided to go for a proprietary option and users had the option to chat from anywhere with anyone. That doesn’t discount Matrix for doing something needed now. Proprietary chat lock-in runs in cycles. Here’s to hoping they don’t adopt & abandon Matrix.
- rakoo 3y ago
  I'm going to reply to some of your points because they're misguided: > resilience against servers going down The matrix model and the XMPP model are different. They solve orthogonal problems. Even the matrix people say it. That's like saying emails are better than github for collaboration because they are resilient against servers going down: it's true, but it's a different model. Not suitable for everyone. > resilience against malicious federation Wait for matrix to be taken up by big tech companies, you'll see spam flooding. I don't welcome it, but it's all about economics > Json instead of XML This is both subjective and shows the lack of understanding that extensibility is, and how json only does 1/10 of what proper XML can do. > unified specification Not all XMPP usages are the same. If you want messaging, you use the compliance suites, which are specs: https://xmpp.org/extensions/inbox/cs-2022.html#im https://xmpp.org/extensions/inbox/cs-2022.html#im > handling of E2EE with multiple devices and message history Has been working for years already: https://xmpp.org/extensions/xep-0384.html https://xmpp.org/extensions/xep-0384.html > not need to rely on other servers for media access Part of the standard installation of prosody and ejabberd, arguably two of the most known servers, for years. A few lines in the conf. Matrix solves problems and creates others. Your information is outdated by almost a decade, which probably explains why you think matrix solves these.
  - spoiler 3y ago
    > > Json instead of XML > > This is both subjective and shows the lack of understanding that extensibility is, and how json only does 1/10 of what proper XML can do. Can you elaborate on this a bit more? Specifically what can XML do that JSON can't? I know the feature set is technically larger (eg namespaces, schemas, etc), but AFAIK all those features aren't necessary for transporting messages. I even consider some things in XML (or at least in common implementations) to be nuisances, like collapsing elements into properties, or some accepting either or both without a schema, and I'm never sure what the precedence rules are. Also, due to being a simpler spec, JSON is more widely available, and generally faster to parse too.
    - rakoo 3y ago
      > Specifically what can XML do that JSON can't? Put XML inside XML, which is most useful for wrapping. Extensibility is built-in, so any parser knows it has to deal with namespaces; it doesn't depend on the flavor of the library. > I know the feature set is technically larger (eg namespaces, schemas, etc), but AFAIK all those features aren't necessary for transporting messages. It's not necessary for transporting messages, but both protocols go way beyond messaging. How do you send an invite for a party and a fallback if it isn't understood by the other side ? In XMPP you use namespaces; in JSON you have to define yet another schema that will only be used by your app and everyone else must copy it. > Also, due to being a simpler spec, JSON is more widely available, and generally faster to parse too. I'd like to see actual numbers of real software before believing the parsing speed even matters. A matrix server has to sync with dozens, sometimes hundreds of servers, some of them being extremely slow. I don't think the speed of parsing changes anything. Plus, the spec is simpler indeed, but it is too simple. Namespaces solve a real problem, it's a mistake to not have them.
- ilyt 3y ago
  None of that were problems that stopped XMPP from being popular. The ones you mentioned are problems nerds had with it, not normal users. Except "unified specification", that's a big one It was simple: UI/UX experience: * each server supported different set of features * each client supported different set of features * some of them (like gateways to other chats) were "generic" enough that power users were needed to set them up, even if they worked extremely well * Most chats were "text-mostly" with shitty html subset, which was just worse for power and normal users alone compared to now-near-standard "markdown + reactions" Will you get your chat history on given combination of client and server ? Who the fuck knows Will you have direct data transfer work ? Who the fuck knows Can you share file to a group chat ? Who the fuck knows "Oh look markdown is popular, lets IMPLEMENT SOMETHING ELSE THAT'S SIMILAR BUT INCOMPATIBLE" https://xmpp.org/extensions/xep-0393.html https://xmpp.org/extensions/xep-0393.html and other great XEPs... I swear whoever is running that is smoking crack And the XEPs. Millions of them. There is no version of protocol to target by client or server, there is not even "level of features" (lets say "text only", "text + voice", "text + video conferencing"), no, pick and choose, and on both server and client site. XMPP is absolute mess and mountain of design by committee
  - rakoo 3y ago
    > There is no version of protocol to target by client or server, there is not even "level of features" (lets say "text only", "text + voice", "text + video conferencing"), no, pick and choose, and on both server and client site. Yes, there is. But your entire comment is based on years-old view of what XMPP was
  - MattJ100 3y ago
    > And the XEPs. Millions of them. 482 of them. A XEP is how someone proposes a feature, and how the community collaborates around the protocol's development. Many XEPs never gain enough traction to be marked as "stable", and they get automatically deferred after a year. This means out of the 482 XEPs, a much smaller number are actually required to implement working stuff in XMPP. Hopefully this solves the common misconception, which you seem to have, that you have to implement every XEP. Some aren't even dealing with protocol changes, some are only informational, and some only pertain to client or server features. > There is no version of protocol to target by client or server, there is not even "level of features" (lets say "text only", "text + voice", "text + video conferencing"), no, pick and choose, and on both server and client site. False. We publish annual "compliance suites" which contains an array of features and two compliance levels for each ("core" and "advanced"). You can browse XMPP software by compliance levels here: https://xmpp.org/software/ https://xmpp.org/software/ You can find the 2022 compliance suite here: https://xmpp.org/extensions/xep-0459.html https://xmpp.org/extensions/xep-0459.html and the 2023 edition is due to be finalized soon. > XMPP is absolute mess and mountain of design by committee This is your subjective opinion. You're welcome to it, of course. But accept that I (and many others) do not necessarily share this opinion.

tcfhgj 3y ago

Matrix basically solves problems of XMPP: - resilience against servers going down - resilience against malicious federation - Json instead of XML - unified specification - handling of E2EE with multiple devices and message history - not need to rely on other servers for media access Probably more, this was just off the top of my head

toastal 3y ago
Matrix has its de facto centralized server in Matrix.org where almost all rooms will have its data sent through because of accounts joining rooms. The servers have been too heavy/expensive for self-hosting that many end up relying on the big servers to use (maybe the Rust server will help, Dendrite?), but the “resilience” mentioned is a big cause for this expense (similar issues with Mastodon). JSON isn’t superior to XML--it can be in some cases but it’s not without drawbacks; experimental EXI could help with the size. XEPs are an ad hoc unified spec, and the buy-into-or-not nature has some advantages where it’s easier to experiment and fallbacks are common even with fragmentation. OMEMO isn’t perfect, but it does cover multi-device encryption and carbons work to get message history. I like Matrix. But I don’t think it’s the only or best solution despite all of the current hype; the XMPP solution should be looked at more often. XMPP offers additional flexibility as well not being limited to just a chat/communications platform where folks use it for presence, UnifiedPush, etc.
- panick21_ 3y ago
  Its not to big to self host. It uses maybe a bit to much memory but anybody that has a real server (more then a Pi) can host it mostly fine. And many do. Most federated system have one large server that has many users.
  - toastal 3y ago
    I hosted an ejabbard server on a 2014 smart phone for a while earlier this year. ejabbard & Prosody are reasonable to host using DDNS on a home network on just about any hardware which is much more accessible and decentralized than needing a “real server”.
- wkat4242 3y ago
  There's many servers on matrix and even synapse isn't that heavy. What bothers me the most about xmpp is that only the barebones stuff is in the main spec and everything else is in extensions which creates a complex maze of support by servers and clients alike. I've used both but I like matrix the most. Its bridges also seem the most mature.
  - toastal 3y ago
    Being barebones is a part of the selling point for an eXtensible platform though. ejabberd came with really good defaults, and Prosody only a little painful (though most of that could be chalked up to DNS being a pain + Nginx behaving unexpectedly). If you need something more turnkey, Snikkit can be useful if you believe Docker is a good idea.
    - wkat4242 3y ago
      > Being barebones is a part of the selling point for an eXtensible platform though. Understood but as a user I don't want core functionality like history to be hidden behind extensions which may or may not be supported or need additional components to client or server. As a user (and home server operator) I found that Matrix+Element gives me a much better user experience with much less fuss (though I admit it was more than 5 years ago when I last ran ejabberd). And the bridges are amazing, just what I needed. Because Matrix is not very useful until everyone uses it, for the transition there are bridges. I don't really care about the underlying architecture, I just want it to easily provide me a modern chat experience.
      - toastal 3y ago
        > core functionality like history I won’t disagree with this. It could be a part of the main spec, but there’s some novelty knowing you could do a ‘complete’ server or client in a day. There are certainly different modern expectations than compared to IRC. Compared to the OP, barebones XMPP is much closer to a ‘simple chat’. > bridges XMPP + libpurple were trying to do similar things. For a hot minute everyone, even the like of Facebook Chat and whatever Google’s chat was named at the time, was using XMPP til they all decided to go for a proprietary option and users had the option to chat from anywhere with anyone. That doesn’t discount Matrix for doing something needed now. Proprietary chat lock-in runs in cycles. Here’s to hoping they don’t adopt & abandon Matrix.
rakoo 3y ago
I'm going to reply to some of your points because they're misguided: > resilience against servers going down The matrix model and the XMPP model are different. They solve orthogonal problems. Even the matrix people say it. That's like saying emails are better than github for collaboration because they are resilient against servers going down: it's true, but it's a different model. Not suitable for everyone. > resilience against malicious federation Wait for matrix to be taken up by big tech companies, you'll see spam flooding. I don't welcome it, but it's all about economics > Json instead of XML This is both subjective and shows the lack of understanding that extensibility is, and how json only does 1/10 of what proper XML can do. > unified specification Not all XMPP usages are the same. If you want messaging, you use the compliance suites, which are specs: https://xmpp.org/extensions/inbox/cs-2022.html#im https://xmpp.org/extensions/inbox/cs-2022.html#im > handling of E2EE with multiple devices and message history Has been working for years already: https://xmpp.org/extensions/xep-0384.html https://xmpp.org/extensions/xep-0384.html > not need to rely on other servers for media access Part of the standard installation of prosody and ejabberd, arguably two of the most known servers, for years. A few lines in the conf. Matrix solves problems and creates others. Your information is outdated by almost a decade, which probably explains why you think matrix solves these.
- spoiler 3y ago
  > > Json instead of XML > > This is both subjective and shows the lack of understanding that extensibility is, and how json only does 1/10 of what proper XML can do. Can you elaborate on this a bit more? Specifically what can XML do that JSON can't? I know the feature set is technically larger (eg namespaces, schemas, etc), but AFAIK all those features aren't necessary for transporting messages. I even consider some things in XML (or at least in common implementations) to be nuisances, like collapsing elements into properties, or some accepting either or both without a schema, and I'm never sure what the precedence rules are. Also, due to being a simpler spec, JSON is more widely available, and generally faster to parse too.
  - rakoo 3y ago
    > Specifically what can XML do that JSON can't? Put XML inside XML, which is most useful for wrapping. Extensibility is built-in, so any parser knows it has to deal with namespaces; it doesn't depend on the flavor of the library. > I know the feature set is technically larger (eg namespaces, schemas, etc), but AFAIK all those features aren't necessary for transporting messages. It's not necessary for transporting messages, but both protocols go way beyond messaging. How do you send an invite for a party and a fallback if it isn't understood by the other side ? In XMPP you use namespaces; in JSON you have to define yet another schema that will only be used by your app and everyone else must copy it. > Also, due to being a simpler spec, JSON is more widely available, and generally faster to parse too. I'd like to see actual numbers of real software before believing the parsing speed even matters. A matrix server has to sync with dozens, sometimes hundreds of servers, some of them being extremely slow. I don't think the speed of parsing changes anything. Plus, the spec is simpler indeed, but it is too simple. Namespaces solve a real problem, it's a mistake to not have them.
ilyt 3y ago
None of that were problems that stopped XMPP from being popular. The ones you mentioned are problems nerds had with it, not normal users. Except "unified specification", that's a big one It was simple: UI/UX experience: * each server supported different set of features * each client supported different set of features * some of them (like gateways to other chats) were "generic" enough that power users were needed to set them up, even if they worked extremely well * Most chats were "text-mostly" with shitty html subset, which was just worse for power and normal users alone compared to now-near-standard "markdown + reactions" Will you get your chat history on given combination of client and server ? Who the fuck knows Will you have direct data transfer work ? Who the fuck knows Can you share file to a group chat ? Who the fuck knows "Oh look markdown is popular, lets IMPLEMENT SOMETHING ELSE THAT'S SIMILAR BUT INCOMPATIBLE" https://xmpp.org/extensions/xep-0393.html https://xmpp.org/extensions/xep-0393.html and other great XEPs... I swear whoever is running that is smoking crack And the XEPs. Millions of them. There is no version of protocol to target by client or server, there is not even "level of features" (lets say "text only", "text + voice", "text + video conferencing"), no, pick and choose, and on both server and client site. XMPP is absolute mess and mountain of design by committee
- rakoo 3y ago
  > There is no version of protocol to target by client or server, there is not even "level of features" (lets say "text only", "text + voice", "text + video conferencing"), no, pick and choose, and on both server and client site. Yes, there is. But your entire comment is based on years-old view of what XMPP was
- MattJ100 3y ago
  > And the XEPs. Millions of them. 482 of them. A XEP is how someone proposes a feature, and how the community collaborates around the protocol's development. Many XEPs never gain enough traction to be marked as "stable", and they get automatically deferred after a year. This means out of the 482 XEPs, a much smaller number are actually required to implement working stuff in XMPP. Hopefully this solves the common misconception, which you seem to have, that you have to implement every XEP. Some aren't even dealing with protocol changes, some are only informational, and some only pertain to client or server features. > There is no version of protocol to target by client or server, there is not even "level of features" (lets say "text only", "text + voice", "text + video conferencing"), no, pick and choose, and on both server and client site. False. We publish annual "compliance suites" which contains an array of features and two compliance levels for each ("core" and "advanced"). You can browse XMPP software by compliance levels here: https://xmpp.org/software/ https://xmpp.org/software/ You can find the 2022 compliance suite here: https://xmpp.org/extensions/xep-0459.html https://xmpp.org/extensions/xep-0459.html and the 2023 edition is due to be finalized soon. > XMPP is absolute mess and mountain of design by committee This is your subjective opinion. You're welcome to it, of course. But accept that I (and many others) do not necessarily share this opinion.