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.
The thing is… What alternatives are there? Signal can’t be trusted (on the very same website there is an article about it). I’m not using closed source alternatives, Simplex is kinda shady too tbh and I’m not even sure I could get anyone to use it.
I don’t like Matrix/Element either but sadly its the best open source chat solution we have.
Signal itself is solid. For now.
The issue is that signal is a centralized infrastructure service that is based in the US.
While it’s rather unlikely that something shady is going on and the current administration manages to pressure someone into installing back doors without anyone noticing, there is a growing chance that at some point the Orange Hitler or his cronies aim at Signal - and simply shut the whole thing down in a single sweep.
Which would mean the whole thing is lost - in theory they of course could rebuild a foundation outside the US, but that would also mean they need people not residing in the US (not like Proton which claims to operate from Switzerland and in reality are US based) and find funding there - enough funding to cover the costs and that is not impeded by US pressure.
This is the scenario that makes Signal a problematic candidate - and sadly the foundation is doing nothing against it.
I started reading the article but didn’t finish. This guy is a fool. He’s bitching about vendor lock in? The data isn’t supposed to be portable. That’s the point.
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”.
The thing is… What alternatives are there? Signal can’t be trusted (on the very same website there is an article about it). I’m not using closed source alternatives, Simplex is kinda shady too tbh and I’m not even sure I could get anyone to use it.
I don’t like Matrix/Element either but sadly its the best open source chat solution we have.
Counterpoint: this is just some random blogger and you don’t need to follow any of their advice.
Why don’t people trust Signal?
Signal itself is solid. For now. The issue is that signal is a centralized infrastructure service that is based in the US.
While it’s rather unlikely that something shady is going on and the current administration manages to pressure someone into installing back doors without anyone noticing, there is a growing chance that at some point the Orange Hitler or his cronies aim at Signal - and simply shut the whole thing down in a single sweep.
Which would mean the whole thing is lost - in theory they of course could rebuild a foundation outside the US, but that would also mean they need people not residing in the US (not like Proton which claims to operate from Switzerland and in reality are US based) and find funding there - enough funding to cover the costs and that is not impeded by US pressure.
This is the scenario that makes Signal a problematic candidate - and sadly the foundation is doing nothing against it.
Its a 18 months old but OP means this on the same site. https://マリウス.com/if-you-must-use-signal-use-molly/
The blogger also stopped using proton mail. So idk. Seems to be their thing atm.
I started reading the article but didn’t finish. This guy is a fool. He’s bitching about vendor lock in? The data isn’t supposed to be portable. That’s the point.
The article author went back to XMPP, which does appear to be the best option currently.
In what universe is XMPP better than Matrix?
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.
xmpp mentioned, I’ll add IRC
Going back to TS3 and IRC. They never left
xmpp?
I forgot to add nextcloud talk!