6 ms·

Recently I'm hearing more about Matrix. Does anyone have any input as to the pros and cons of Matrix vs xmpp?

fyfy18 8y ago
It's quite subjective, but my view is Matrix is what XMPP would like if it was written today. The main advantages are it is using JSON instead of XML, and HTTP instead of custom protocols so it can work directly from browsers and with lightweight mobile clients. It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them). The only con is it's still a relatively young project. I'm not sure I would want to rely on it as my main form of communication in a company just yet, but for personal usage it is fine.
- jauco 8y ago
  I might be mistaken, but from what I read the main addition is that all peers replicate the full state. If you have a dominant xmpp server (like gmail was) that removes xmpp support, its users have the start using other clients to connect to it or start a new social structure from scratch. In essence this makes the xmpp server a dominant player with leverage. If gmail had used matrix when it pulled the plug all interactions (who knows who, how to route traffic, chat history) would have been replicated at the peers so it would just have removed google’s servers from the equation. The people who had been using it would continue uninterrupted.
  - Squithrilve 8y ago
    > The people who had been using it would continue uninterrupted. I'm not sure about that. If the main matrix server disappeared today that'd be problematic. Yes, you'd have history locally but the same can be said for any native client that stores history locally. As far as I know there is no way to migrate matrix history now. Is there? (genuinely curious)
    - zinid 8y ago
      > I'm not sure about that. If the main matrix server disappeared today that'd be problematic This ^^ Currently a large amount of users (I'm told around a half, but I'm not sure) have matrix.org as their home server. So Matrix is effectively building a power-law network with all its drawbacks: when the "power node" of the network goes down the whole network falls apart.
      - pferde 8y ago
        To be fair, this is somewhat inevitable in the initial stages, before a reasonable spec is released. Many people, like me, are just "sitting on the fence" and test-driving Matrix via their matrix.org server, until there are reasonable assurances that deploying our own Matrix server will come without too much hassle. After Synapse 1.0 is released (sometimes next month, IIRC), I'm definitely deploying my own homeserver, and federating it with the rest of the world.
        majewsky 8y ago
        FWIW, I've been running Synapse since 0.20 or so (for at least 2 years now), and there has never been a breaking change in the protocol as far as I'm aware. I had to read release notes at some points to get the upgrade to work, but it was mostly Python-library-related stuff IIRC.
      - omnimus 8y ago
        Well they are making one big instance nothing else. Also unfortunately it means that you can't possibly federate with matrix.org. I've been running small otherwise perfectly functioning instance for few years for my circle/work as slack alternative on small vps. One time i did the amazing mistake of turning on federation with matrix.org. It immediately killed my servers performance especially when i joined some popular channel. The channels probably have more messages than my whole server combined. And it works the other way too - matrix.org is like sponge sucking other instances. I guess this is the real problem for me - i would love to federate but i can't possibly police or enforce what servers/channels are small enough that my users can join them.
  - rakoo 8y ago
    You're both right and wrong. In both cases, if users have an account on gmail and are using it, and gmail pulls the plug, then they can't use it anymore and can't migrate. The history is still there in the case of matrix, but they can't reuse the same account. However if another user is homed on another server, they would still keep the knowledge and history on their side: gmail did pull the plug on xmpp, yet people are still using it. Their server still know who their contacts are, what room they're usually in, etc... Matrix does have the advantage that the chat history is fully replicated on all homeservers so it makes history retrieval much saner, but that's it. Matrix doesn't route traffic (messages go from sender's homeserver to recipients' homeservers, that's it) and doesn't share client's information with the whole world.
    - jauco 8y ago
      Too bad. Well consider this a feature request then ;)
- zinid 8y ago
  > It's quite subjective, but my view is Matrix is what XMPP would like if it was written today. That's indeed a subjective view. > The main advantages are it is using JSON instead of XML, and HTTP instead of custom protocols The Matrix dev said a day ago that "It's NOTHING to do with HTTP+JSON": https://news.ycombinator.com/item?id=19217412 https://news.ycombinator.com/item?id=19217412 Also, what custom protocol are you talking about? XMPP works on top of TCP/TLS (or Websocket). Those are the IETF standards. In fact XMPP doesn't require an additional layer of HTTP at all. > with lightweight mobile clients Where are they? Anything even remotely comparable battery-wise with Conversations (an XMPP client)? Not to mention that Matrix has a terrible server implementation which requires several GB of RAM just to join matrix.org room. > It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them). I fail to see how having a monolith core versus splitted specs has to do anything with code written to support that. Of course, initially every implementation will strive to implement full core (that was in XMPP in 2000s), but when the core evolves you have absolutely no guarantee that every developer will implement all new parts of the core. How is that addressed in Matrix?
  - allende12 8y ago
    > How is that addressed in Matrix? Well that's quite easy, since hosting a server is a resource hog, most people are still on matrix.org, which gives it a special status in the ecosystem (even more special than jabber.org has been in the early 2000s fox XMPP). This allows them to "move fast and break stuff" on short notice (a few months), to bring the protocol forward and force people to upgrade. In the federated XMPP ecosystem, they essentially have to come to a community consensus between developers, servers operators and all other relevant actors to write a manifesto or a new spec that says "stop using $thing at $date". In my opinion matrix, while being open-source, federated and easy to write clients for, is still a half-locked platform because essentially the matrix.org server is "too big to fail", and the matrix team is the only one who can e.g. offer consultancy over the protocol because nobody else can have a long-term view of its future evolutions (of course the matrix people are nice, and you can discuss with them, but that is still not a standards body).
- tannhaeuser 8y ago
  I can't see any advantage in using JSON and HTTP for a protocol. JSON shines for ad-hoc, untyped, structured message payloads rather than the strongly-typed semistructured text payloads possible with XML/SGML, and HTTP wasn't designed for federated protocols. It seems more like a fashion thing to me.
  - forty 8y ago
    I kind of agree with you, but I'll add that XMPP usage of XML is weird enough that it makes it hard it use a normal XML parser / producer. Honestly I really wanted to like XMPP. I read all the specs at the time, even started to write some code, but all I can say is that it really sucks. I haven't looked at matrix yet, I hope it's better
    - eeZah7Ux 8y ago
      Also flexibility can be good but XMPP is way too modular.
      - edhelas 8y ago
        You don't have to implement all the modules :p There is some basic ones that you need (see XEP-0412: XMPP Compliance Suites 2019 - https://xmpp.org/extensions/xep-0412.html https://xmpp.org/extensions/xep-0412.html) and you have already an up to date client and server. The rest if for specific use cases.
    - olau 8y ago
      Indeed! I was in the same boat - also started writing a client, but wasted too much time on the stupid XML stream idea. Basically, chatting is message oriented, but the XMPP inventors thought it would be neat to start the connection with a tag like <beginconversation> which would then be dangling for the whole connection, preventing the use of a simple DOM XML parser (remember this is many years ago) for each message.
      - edhelas 8y ago
Zash 8y ago
From the point of view of an XMPP server developer, the main advantage of Matrix seems to be that they have a well-funded marketing department.
- Arathorn 8y ago
  we really don’t, fwiw. we have zero money assigned to marketing and nobody working on it, unless you count me chatting on HN and twitter, or our designer or the guy who updates the matrix.org/blog?
arendtio 8y ago
Well, technically both are valid approaches which get messages from one user to another in a federated way. Besides that, XMPP is an IETF standard which has proven it can adapt to changing requirements. Matrix, on the other hand, is a young project with more momentum and more consistent software landscape. That said, I have quite a biased view on the topic, as I kinda blame the Matrix devs for splitting the federated communication community. XMPP is quite capable of delivering what everyone expects it to do. But lately, developers seem to be more interested in the new Matrix protocol (just because it is new). At the same time, many XMPP clients do not implement all of the latest features the standard has to offer and I wonder what the world would look like if the Matrix devs would have spent their energy on improving existing XMPP clients instead of inventing another protocol. Edit: For completeness, you might like to take a look at the Matrix FAQ https://matrix.org/docs/guides/faq.html#what-is-the-difference-between-matrix-and-xmpp%3F https://matrix.org/docs/guides/faq.html#what-is-the-differen...
Perceptes 8y ago
There's a comparison between the two from the Matrix team's point of view in their FAQ: https://matrix.org/docs/guides/faq#what-is-the-difference-between-matrix-and-xmpp https://matrix.org/docs/guides/faq#what-is-the-difference-be...
upofadown 8y ago
It is possible to consider them different categories of things. XMPP solves the IM problem but conferences with lots of users are a bit awkward if you use a XMPP MUC server. Conferencing is to some extent a bag on the side of XMPP. You would probably be better off just using IRC. Matrix is primarily about dealing with the issues of conferences with lots of users... I see it as more of an improved IRC than a replacement for XMPP.

It's quite subjective, but my view is Matrix is what XMPP would like if it was written today. The main advantages are it is using JSON instead of XML, and HTTP instead of custom protocols so it can work directly from browsers and with lightweight mobile clients. It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them). The only con is it's still a relatively young project. I'm not sure I would want to rely on it as my main form of communication in a company just yet, but for personal usage it is fine.

jauco 8y ago
I might be mistaken, but from what I read the main addition is that all peers replicate the full state. If you have a dominant xmpp server (like gmail was) that removes xmpp support, its users have the start using other clients to connect to it or start a new social structure from scratch. In essence this makes the xmpp server a dominant player with leverage. If gmail had used matrix when it pulled the plug all interactions (who knows who, how to route traffic, chat history) would have been replicated at the peers so it would just have removed google’s servers from the equation. The people who had been using it would continue uninterrupted.
- Squithrilve 8y ago
  > The people who had been using it would continue uninterrupted. I'm not sure about that. If the main matrix server disappeared today that'd be problematic. Yes, you'd have history locally but the same can be said for any native client that stores history locally. As far as I know there is no way to migrate matrix history now. Is there? (genuinely curious)
  - zinid 8y ago
    > I'm not sure about that. If the main matrix server disappeared today that'd be problematic This ^^ Currently a large amount of users (I'm told around a half, but I'm not sure) have matrix.org as their home server. So Matrix is effectively building a power-law network with all its drawbacks: when the "power node" of the network goes down the whole network falls apart.
    - pferde 8y ago
      To be fair, this is somewhat inevitable in the initial stages, before a reasonable spec is released. Many people, like me, are just "sitting on the fence" and test-driving Matrix via their matrix.org server, until there are reasonable assurances that deploying our own Matrix server will come without too much hassle. After Synapse 1.0 is released (sometimes next month, IIRC), I'm definitely deploying my own homeserver, and federating it with the rest of the world.
      - majewsky 8y ago
        FWIW, I've been running Synapse since 0.20 or so (for at least 2 years now), and there has never been a breaking change in the protocol as far as I'm aware. I had to read release notes at some points to get the upgrade to work, but it was mostly Python-library-related stuff IIRC.
    - omnimus 8y ago
      Well they are making one big instance nothing else. Also unfortunately it means that you can't possibly federate with matrix.org. I've been running small otherwise perfectly functioning instance for few years for my circle/work as slack alternative on small vps. One time i did the amazing mistake of turning on federation with matrix.org. It immediately killed my servers performance especially when i joined some popular channel. The channels probably have more messages than my whole server combined. And it works the other way too - matrix.org is like sponge sucking other instances. I guess this is the real problem for me - i would love to federate but i can't possibly police or enforce what servers/channels are small enough that my users can join them.
- rakoo 8y ago
  You're both right and wrong. In both cases, if users have an account on gmail and are using it, and gmail pulls the plug, then they can't use it anymore and can't migrate. The history is still there in the case of matrix, but they can't reuse the same account. However if another user is homed on another server, they would still keep the knowledge and history on their side: gmail did pull the plug on xmpp, yet people are still using it. Their server still know who their contacts are, what room they're usually in, etc... Matrix does have the advantage that the chat history is fully replicated on all homeservers so it makes history retrieval much saner, but that's it. Matrix doesn't route traffic (messages go from sender's homeserver to recipients' homeservers, that's it) and doesn't share client's information with the whole world.
  - jauco 8y ago
    Too bad. Well consider this a feature request then ;)
zinid 8y ago
> It's quite subjective, but my view is Matrix is what XMPP would like if it was written today. That's indeed a subjective view. > The main advantages are it is using JSON instead of XML, and HTTP instead of custom protocols The Matrix dev said a day ago that "It's NOTHING to do with HTTP+JSON": https://news.ycombinator.com/item?id=19217412 https://news.ycombinator.com/item?id=19217412 Also, what custom protocol are you talking about? XMPP works on top of TCP/TLS (or Websocket). Those are the IETF standards. In fact XMPP doesn't require an additional layer of HTTP at all. > with lightweight mobile clients Where are they? Anything even remotely comparable battery-wise with Conversations (an XMPP client)? Not to mention that Matrix has a terrible server implementation which requires several GB of RAM just to join matrix.org room. > It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them). I fail to see how having a monolith core versus splitted specs has to do anything with code written to support that. Of course, initially every implementation will strive to implement full core (that was in XMPP in 2000s), but when the core evolves you have absolutely no guarantee that every developer will implement all new parts of the core. How is that addressed in Matrix?
- allende12 8y ago
  > How is that addressed in Matrix? Well that's quite easy, since hosting a server is a resource hog, most people are still on matrix.org, which gives it a special status in the ecosystem (even more special than jabber.org has been in the early 2000s fox XMPP). This allows them to "move fast and break stuff" on short notice (a few months), to bring the protocol forward and force people to upgrade. In the federated XMPP ecosystem, they essentially have to come to a community consensus between developers, servers operators and all other relevant actors to write a manifesto or a new spec that says "stop using $thing at $date". In my opinion matrix, while being open-source, federated and easy to write clients for, is still a half-locked platform because essentially the matrix.org server is "too big to fail", and the matrix team is the only one who can e.g. offer consultancy over the protocol because nobody else can have a long-term view of its future evolutions (of course the matrix people are nice, and you can discuss with them, but that is still not a standards body).
tannhaeuser 8y ago
I can't see any advantage in using JSON and HTTP for a protocol. JSON shines for ad-hoc, untyped, structured message payloads rather than the strongly-typed semistructured text payloads possible with XML/SGML, and HTTP wasn't designed for federated protocols. It seems more like a fashion thing to me.
- forty 8y ago
  I kind of agree with you, but I'll add that XMPP usage of XML is weird enough that it makes it hard it use a normal XML parser / producer. Honestly I really wanted to like XMPP. I read all the specs at the time, even started to write some code, but all I can say is that it really sucks. I haven't looked at matrix yet, I hope it's better
  - eeZah7Ux 8y ago
    Also flexibility can be good but XMPP is way too modular.
    - edhelas 8y ago
      You don't have to implement all the modules :p There is some basic ones that you need (see XEP-0412: XMPP Compliance Suites 2019 - https://xmpp.org/extensions/xep-0412.html https://xmpp.org/extensions/xep-0412.html) and you have already an up to date client and server. The rest if for specific use cases.
  - olau 8y ago
    Indeed! I was in the same boat - also started writing a client, but wasted too much time on the stupid XML stream idea. Basically, chatting is message oriented, but the XMPP inventors thought it would be neat to start the connection with a tag like <beginconversation> which would then be dangling for the whole connection, preventing the use of a simple DOM XML parser (remember this is many years ago) for each message.
    - edhelas 8y ago

Zash 8y ago

From the point of view of an XMPP server developer, the main advantage of Matrix seems to be that they have a well-funded marketing department.

Arathorn 8y ago
we really don’t, fwiw. we have zero money assigned to marketing and nobody working on it, unless you count me chatting on HN and twitter, or our designer or the guy who updates the matrix.org/blog?

arendtio 8y ago

Well, technically both are valid approaches which get messages from one user to another in a federated way. Besides that, XMPP is an IETF standard which has proven it can adapt to changing requirements. Matrix, on the other hand, is a young project with more momentum and more consistent software landscape. That said, I have quite a biased view on the topic, as I kinda blame the Matrix devs for splitting the federated communication community. XMPP is quite capable of delivering what everyone expects it to do. But lately, developers seem to be more interested in the new Matrix protocol (just because it is new). At the same time, many XMPP clients do not implement all of the latest features the standard has to offer and I wonder what the world would look like if the Matrix devs would have spent their energy on improving existing XMPP clients instead of inventing another protocol. Edit: For completeness, you might like to take a look at the Matrix FAQ https://matrix.org/docs/guides/faq.html#what-is-the-difference-between-matrix-and-xmpp%3F https://matrix.org/docs/guides/faq.html#what-is-the-differen...

Perceptes 8y ago

There's a comparison between the two from the Matrix team's point of view in their FAQ: https://matrix.org/docs/guides/faq#what-is-the-difference-between-matrix-and-xmpp https://matrix.org/docs/guides/faq#what-is-the-difference-be...

upofadown 8y ago

It is possible to consider them different categories of things. XMPP solves the IM problem but conferences with lots of users are a bit awkward if you use a XMPP MUC server. Conferencing is to some extent a bag on the side of XMPP. You would probably be better off just using IRC. Matrix is primarily about dealing with the issues of conferences with lots of users... I see it as more of an improved IRC than a replacement for XMPP.