It's more that Matrix is different to Jabber/XMPP.
In Matrix, your chatrooms synchronise chat history between servers (rather than passing messages around), and that history is replicated equally over the participating servers, a bit like Git.
In XMPP, you pass messages between clients on different servers using a given server as a hub, and clients can choose to back up their message history on their local server.
Which architecture you prefer probably depends on whether you think instant messaging should be about passing messages or archiving chat history.
> In Matrix, your chatrooms synchronise chat history between servers (rather than passing messages around), and that history is replicated equally over the participating servers, a bit like Git.
XMPP had FMUC (Federated Multi-User Chats) about 5 years before Matrix was even invented. It didn't see broader adoption in the XMPP world because the community figured that this isn't a problem worth solving, and/or that the incurred complexity isn't worth it.
And worse, Matrix even hasn't found an adequate and scalable solution for this "proud" ambition (and probably never will). I don't expect that you could demonstrate in good faith that distributed state and its resolution are a net positive for Matrix, its community, its ecosystem, nor that it has opened new possibilities for the practical cases and users. We are back from the blockchain hype/hangover already, and I can't wait for the same thing to happen to Matrix: this was the wrong tool for the job. Just let it go.
Jabber core protocol (XMPP) is kinda like SMTP. It deals with transmission of messages between two peers. Just like with SMTP, you can federate servers, so they can exchange messages between each other.
And the similarities don't end here. XMPP doesn't have built-in support for encryption (apart from the basic TLS encryption for the transport layer), it doesn't have support for message archiving and chat history syncing, there is no support for group chats, and so on.
A lot of this functionality is added as extensions (e.g. group chats are XEP-045), but this simply caused a lot of fragmentation in the ecosystem. So you could never rely on your client (or server) interoperating with other clients properly.
Audio calls and video also never really worked well. Google tried to push them by releasing libjingle in 2006 (!!!) but it was kinda ignored by everyone.
Most of criticism of XMPP with regards to fragmentation and extensions can be applied to Matrix as well. In fact, the sliding sync itself already fragments the ecosystem by not being supported out of the box by many server implementations and therefore homeservers. Encryption often has to be enabled with some machinations as well if we're talking about clients other than Element (and electron-based).
On the other hand, XMPP desktop clients certainly work better and faster than Element, although some of them look quite old, which doesn't take away from their functionality.
IMO it's being heavily overstated how Matrix is better than XMPP.
This criticism kinda misses the point. E2EE, especially for group chats, is _the_ reason to use Matrix. It's an extremely hard problem, and you'll basically need to replicate what Matrix does if you want to solve it.
Doubly so when you add federation.
It required more than one iteration of Matrix to get it right, which I (personally) totally expected to happen. I don't think XMPP will _ever_ get it right.
Regarding clients, I don't think Element is worse than most (all?) XMPP clients when you look at the functionality past simple 1-to-1 messaging. And forget about mobile apps, XMPP just sucks on mobile.
> E2EE, especially for group chats, is _the_ reason to use Matrix. It's an extremely hard problem, and you'll basically need to replicate what Matrix does if you want to solve it.
I would be inclined to call this FUD. XMPP had E2EE before Signal and Matrix even were released. Current XMPP uses a flavour of double ratchet encryption (OMEMO) that puts it in par with those two, while working on MLS (just like Matrix).
> And forget about mobile apps, XMPP just sucks on mobile.
And yet, Conversations uses a fraction of the energy and resources Element requires. And does audio/video calls more reliably. And works well for 1:1 to large chat groups with thousands of participants.
I am actively using E2EE in matrix group chats daily. It is absolutely horrible. Matrix has not gotten it right.
It is a typical situation to observe "Failed to decrypt message" across the whole chat history. It is typical to observe reordering or even lack of messages, which make reading the chat unbearable. It is typical to have problems with session validation.
On one account I have even lost the validated status of another member's sessions, even though we have validated each other before and the only thing that changed is that they logged in with a different client. Since we live in different countries far away from each other, we just have to look at the red shield every time we open the chat and keep in mind that it's not a MITM but just a Matrix failure.
> XMPP just sucks on mobile
So does Element. I have <10 chats joined, and every time I open the Element app I have to wait for 10+ secs before I can start reading new messages. This will surely be fixed by sliding sync, but it's a problem of its own.
IIUC Jabber never really had decentralized group chats? It had MUC but these were federated, so if the server hosting the room went down the chat also died.
Matrix rooms are fully decentralized and can survive any servers failing.
(Although note that not much else in the protocol is decentralized, much of it is only federated.)
> IIUC Jabber never really had decentralized group chats?
Jaber had something like that 5 years before Matrix: https://xmpp.org/extensions/xep-0289.html but decided it wasn't an avenue worth pursuing, as a non-issue in practice. This is further proven by WhatsApp (which is based on XMPP/ejabberd) and its billion active users: you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure (the erlang VM in this case).
> Matrix rooms are fully decentralized and can survive any servers failing.
In practice the room survives in a "split brain" mode where different users see different participants, the room isn't available to the users whose instance went dark as its no longer hosting their identity, and messages are popping mid history while the state resolution is working hard to reach consensus. When the servers finally come back online, there is a risk of never catching up fully, or worse, for the rooms to remain split forever.
And I adventure a hot take there: this property of staying seemingly online (in a frankenbizarre way) came handy way fewer times in the history of Matrix than for all the incurred complexity reflected in daily bugs, privacy, security, performance issues and inconsistencies.
To add some colour - there are commercial implementations of that (e.g. https://www.isode.com/whitepapers/federated-muc.html ). But from my perspective as a server developer, I've seen minimal interest in this for the public network. Probably because server failures are rare enough events in the general case.
That's not to say there aren't use cases where it is more valuable to have this functionality.
> you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure
But I don't want to trust my community to someone providing me infrastructure. Lots of projects, communities or whatever start small on third-party hosting. Many open source projects right now have rooms on gitter.im or matrix.org. I don't think they made a "bad" choice and I don't think they should need to scramble to find new rooms if their provider goes offline.
> In practice the room survives in a "split brain" mode where different users see different participants
Even if this is true (I haven't see it when servers go offline) this sounds like a bug that can be improved over time. Not a reason to give up.
But also do you have any evidence of this? Matrix rooms don't have a "home server" so if this was a bug that occurred it would occur for any member of a chat going temporarily offline, and for large chats that happens often. So it seems like if this is an issue it only happens in very niche circumstances.
> isn't available to the users whose instance went dark as its no longer hosting their identity
This is true, as I said users are federated and suffer if their homeserver goes down. But it is a huge difference to be able to set up a second account on a second server and continue participating rather than needing to convince a large group of people to switch to a different room.
Look at freenode for example. It was fairly organized as far as shifting a massive group of communities goes but still quite messy. In the matrix scenario rooms could have moved by simply adding new admin accounts on different homeservers and kicking or demoting all admin accounts on freenode. The users wouldn't have to do anything (except moving away from freenode accounts if they prefer).
>> you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure
> But I don't want to trust my community to someone providing me infrastructure.
I mean, that's always the case in the end, isn't it? Your identity is tied to your server, and that's pretty much what defines the whole thing as being a federation and not P2P (that applies equally for XMPP as for Matrix).
As long as migrating from provider to provider is easy and convenient (which amounts to acknowledging that all providers eventually come and go, what centralized service users are in denial about), I don't see it as being a fundamental issue.
It's also easier to mitigate this aspect in XMPP-world where being your own provider is orders of magnitude easier and cheaper compared to running a matrix homeserver and federating at scale.
Also, talking about infrastructure, the situation is quite worrisome in the case of Matrix, I'd say: only one entity is competent enough (or has enough cash committed) to running large-scale: new vector. And it runs that of matrix.org, kde.org, fedora.org, mozilla.org, …. It also happens to be the one specifying and implementing the (incompletely documented) protocol, conveniently.
>> In practice the room survives in a "split brain" mode where different users see different participants
> Even if this is true (I haven't see it when servers go offline) this sounds like a bug that can be improved over time. Not a reason to give up.
It's a very very hard problem to crack. They've been at it for 10 years across many iterations of the protocol: https://telegra.ph/why-not-matrix-08-07 . I like to think that it can be solved the same way I want to have closure about P=NP, but I also challenge that this is a meaningful and practical approach in this context.
> This is true, as I said users are federated and suffer if their homeserver goes down. But it is a huge difference to be able to set up a second account on a second server and continue participating rather than needing to convince a large group of people to switch to a different room.
Yup, and that's all pretty and neat in theory. In practice it happens every so often that rooms just break for inexplicable reasons, and that people must migrate anyway. Not all members do, because for some, everything still looks like business as usual (happened again few months ago with the 3D Printing space), and trust me, this is much more eventful and disruptive than freenode committing seppuku once every quarter century, or with large XMPP networks going under.
(disclaimer: I have no knowledge about neither spec, I'm not suggesting Jabber was better)