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.
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”.
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”.