The Matrix.org network has great potential, but after years of dealing with glitches, slow performance, poor UX, and one too many failures, I’m done with it.
XMPP is significantly less decentralized, allowing them to “”“cut corners”“” compared to Matrix protocol implementation, and scale significantly better. (In heavy quotes, as XMPP isn’t really cutting corners, but true decentralization requires more work to achieve seemingly “the same result”)
An XMPP or IRC channel with a few thousand users is no problem, wheras Matrix can have problems with that. On the other hand, any one Matrix homeserver going down does not impact users that aren’t specifically on that homeserver, whereas XMPP is centralized enough that it can take down a whole channel.
Meanwhile IRC is a 90s protocol that doesn’t make any sense in the modern world of mainly mobile devices.
XMPP also doesn’t change much, the last proper addition to the protocol (from what I can tell, on the website) was 2024-08-30 https://xmpp.org/extensions/xep-0004.html
XMPP doesn’t change very very often, but there’s actually tons of XEPs that are in common use and are considered functionally essential for a modern client, and with much higher numbers than XEP-0004
The good news, though, is that mostly you as the user don’t need to care about those! Most of the modern clients agree on the core set and thus interoperate fine for most normal things. And most XEPs have a fallback in case the receiver doesn’t support the same XEPs.
I’m general XMPP as a protocol is a lightweight core that supports an interesting soup of modules (in the form of XEPs) to make it a real messenger in the modern sense. And I think that’s neat! But you can’t really judge the core to say how often things change.
Most of the modern clients agree on the core set and thus interoperate fine for most normal things.
So you think it is a sane solution to mark essential features as optional extensions and then have a wink-wink, nudge-nudge agreement of which of these “optional” extensions are actually mandatory? Instead of having essential features be part of the core protocol?
But more importantly, XMPP sucks because it does not have one back-end implementation like Vodozemac for Matrix. So let alone being unable to have security audits, you are forcing client developers to roll their own implementation of the e2ee, with likely little to no experience with cyber-security, and just hoping they will make no mistakes. You know, implementing encryption that even experts have hard time getting right.
Honestly, I struggle with this myself. On the one hand I like the diversity of clients; it feels like a sign of strength of the community and protocol that there are many options that have different values. But the cost of this diversity is that it makes things more complicated to coordinate, and different people with different values have different opinions on what a chat client should even want for features.
Something like Slack or Discord can roll out a server feature and client feature to all their clients all at the same time and have a unified experience. But the whole benefit of FLOSS is that anyone can fork the client to make changes, and the whole point of an open protocol is that multiple independent clients can interoperate, and so there’s a kind of irony in me wanting those things, but those things producing a fractured output.
So I think XMPP, as a protocol, does the best compromise. These differences between clients and servers aren’t just random changes in behaviour or undocumented features, they’re named, numbered, alterations that live somewhere and are advertised in the built-in “discovery” protocols. The protocol format itself is extensible, so unexpected content can be passed alongside known content in a message or a server response and the clients all know to ignore anything they don’t understand, and virtually all of the XEPs are designed with some kind of backwards compatibility in mind for how this feature might degrade when sent to a non-supported client.
It isn’t perfect, but I think perfection is impossible here. A single server and client that everyone uses and keeps up to date religiously with forced upgrades is best for cohesiveness, but worst for “freedom”, and a free-for-all where people just make random individual changes and everything is always broken isn’t really a community, and XMPP sits in the middle and has a menu of documented deviations for clients to advertise and choose.
As for security, that can be mostly solved with libraries, independent of the rest of the client or server implementation. Like, most clients used libsignal for their crypto, so that could in theory be audited and bug-fixed and all clients would benefit. Again, not perfect, there’s always room at the interface between the client code and the library code that’s unique, but it’s not as bad as rolling your own crypto.
I am yet to see a universal tool that is good at everything. Trying to cram all use-cases into one network results in mediocre results at best and usually even worse.
There is no reason to combine a person to person messenger like signal and community based one like discord into one network. That is why I like the Matrix approach of 1 backend library and many frontends so you can have your pick of clients without messing up the protocol.
Even having the fallbacks for missing features does not solve the issue. The experience for the average person will still be bad. While you and I may enjoy doing research on which client is best for us, most users will see the sub-par experience and leave for a corporate solution that “just works”.
XMPP is significantly less decentralized, allowing them to “”“cut corners”“” compared to Matrix protocol implementation, and scale significantly better. (In heavy quotes, as XMPP isn’t really cutting corners, but true decentralization requires more work to achieve seemingly “the same result”)
An XMPP or IRC channel with a few thousand users is no problem, wheras Matrix can have problems with that. On the other hand, any one Matrix homeserver going down does not impact users that aren’t specifically on that homeserver, whereas XMPP is centralized enough that it can take down a whole channel.
Meanwhile IRC is a 90s protocol that doesn’t make any sense in the modern world of mainly mobile devices.
XMPP also doesn’t change much, the last proper addition to the protocol (from what I can tell, on the website) was 2024-08-30 https://xmpp.org/extensions/xep-0004.html
XMPP doesn’t change very very often, but there’s actually tons of XEPs that are in common use and are considered functionally essential for a modern client, and with much higher numbers than XEP-0004
The good news, though, is that mostly you as the user don’t need to care about those! Most of the modern clients agree on the core set and thus interoperate fine for most normal things. And most XEPs have a fallback in case the receiver doesn’t support the same XEPs.
I’m general XMPP as a protocol is a lightweight core that supports an interesting soup of modules (in the form of XEPs) to make it a real messenger in the modern sense. And I think that’s neat! But you can’t really judge the core to say how often things change.
So you think it is a sane solution to mark essential features as optional extensions and then have a wink-wink, nudge-nudge agreement of which of these “optional” extensions are actually mandatory? Instead of having essential features be part of the core protocol?
But more importantly, XMPP sucks because it does not have one back-end implementation like Vodozemac for Matrix. So let alone being unable to have security audits, you are forcing client developers to roll their own implementation of the e2ee, with likely little to no experience with cyber-security, and just hoping they will make no mistakes. You know, implementing encryption that even experts have hard time getting right.
Honestly, I struggle with this myself. On the one hand I like the diversity of clients; it feels like a sign of strength of the community and protocol that there are many options that have different values. But the cost of this diversity is that it makes things more complicated to coordinate, and different people with different values have different opinions on what a chat client should even want for features.
Something like Slack or Discord can roll out a server feature and client feature to all their clients all at the same time and have a unified experience. But the whole benefit of FLOSS is that anyone can fork the client to make changes, and the whole point of an open protocol is that multiple independent clients can interoperate, and so there’s a kind of irony in me wanting those things, but those things producing a fractured output.
So I think XMPP, as a protocol, does the best compromise. These differences between clients and servers aren’t just random changes in behaviour or undocumented features, they’re named, numbered, alterations that live somewhere and are advertised in the built-in “discovery” protocols. The protocol format itself is extensible, so unexpected content can be passed alongside known content in a message or a server response and the clients all know to ignore anything they don’t understand, and virtually all of the XEPs are designed with some kind of backwards compatibility in mind for how this feature might degrade when sent to a non-supported client.
It isn’t perfect, but I think perfection is impossible here. A single server and client that everyone uses and keeps up to date religiously with forced upgrades is best for cohesiveness, but worst for “freedom”, and a free-for-all where people just make random individual changes and everything is always broken isn’t really a community, and XMPP sits in the middle and has a menu of documented deviations for clients to advertise and choose.
As for security, that can be mostly solved with libraries, independent of the rest of the client or server implementation. Like, most clients used libsignal for their crypto, so that could in theory be audited and bug-fixed and all clients would benefit. Again, not perfect, there’s always room at the interface between the client code and the library code that’s unique, but it’s not as bad as rolling your own crypto.
I am yet to see a universal tool that is good at everything. Trying to cram all use-cases into one network results in mediocre results at best and usually even worse.
There is no reason to combine a person to person messenger like signal and community based one like discord into one network. That is why I like the Matrix approach of 1 backend library and many frontends so you can have your pick of clients without messing up the protocol.
Even having the fallbacks for missing features does not solve the issue. The experience for the average person will still be bad. While you and I may enjoy doing research on which client is best for us, most users will see the sub-par experience and leave for a corporate solution that “just works”.
IRC makes sense in a world where people register to bouncers, which allow people to connect to any IRC network they please.