Highlights include Sliding Sync (instant login/launch/sync), Native OIDC (industry-standard authentication), Native Group VoIP (end-to-end encrypted large-scale voice & video conferencing) and Faster Joins (lazy-loading room state when your server joins a room).
I will get shit for writing that, but Matrix in its current form shouldn’t have seen the light of the day, nor should have been let to spread with close to no technical scrutiny and based on empty promises/hype like it did.
Just to be clear, I’m absolutely encouraging, in fact, actively promoting federated alternatives to things like WhatsApp, Messenger, Signal, Telegram, …
But I don’t believe for a second that the foundations on which Matrix is built make sense, can be made to work well in practice, nor represent a problem worth spending so much time and effort solving. This article does a good job at introducing the “behind the scenes” of the protocol: https://telegra.ph/why-not-matrix-08-07
The whole history of Matrix can be summarized as:
“let’s do this because it’s cool”
“shit, it’s hard/slow, but we will figure it out”
“I have a breakthrough, here comes a new version of the protocol/client/…” (the ecosystem reboots)
(rinse and repeat)
Matrix has seen more incompatible reincarnations of itself in the last 5 years than XMPP in the last 20. Arathorn, its lead contributor and evangelist will keep apologizing, promising that this time they have their stuff in order, that whatever buzzword will solve this or that aspect of the problem, while the elephant still is in the room. You practically can’t tell apart arathorn’s messages of 2015 from those of 2022 and that would be funny if it wasn’t so sad.
IMO Matrix is broken beyond repair, while XMPP is quietly used by millions of users. I wish Matrix could carry its own weight and be so unambiguously better that we wouldn’t need competing alternatives there. To me, the better XMPP is XMPP itself, and I’d be happy to elaborate on that.
I agree in theory, but in practice my experience with Matrix has been infinitely better than with XMPP:
Matrix may be technically complex, but at least it has managed to keep its ecosystem together. Whenever I’ve faced an issue with my server, all I needed to do was upgrade synapse. The “millions of users” in XMPP are mostly all on their own silos, while I am yet to have an issue where I want to chat with someone on Matrix but couldn’t because their client/server was not compatible with mine.
Yep, I’m absolutely appreciative of the good work put together by the Matrix folks on the client side, element is overall okay (although slow, quirky, unstable, …) because of fighting a misguided and unstable server and protocol.
To answer your points:
https://siskin.im/
I would argue that https://movim.eu/ is at least as good as element web. https://conversejs.org/ does the job to bridge across native clients.
What is there to set up? The experience is very comparable to Signal and al. What did you find painful?
How so? It depends on the client, but on Conversations it’s a matter of clicking on + → “Create private group chat” or “Create public channel”. In gajim it’s + → “Create group chat”
For calls to work, you need to use a stun/turn server (like everything everywhere else, including Matrix, Jitsi Meet, …). If you self-host, and you have a recent ejabberd, it’s configured out of the box and you just have to open server ports.
Another way to put it, is that matrix is technically so complex that only a single party can afford to develop and maintain a working implementation. The documentation is lacking and alternative implementations are incompatible in effect. This isn’t a sustainable situation (that those who define the standard are the ones implementing it) and we have started to see the cascading effects of that with the bitrot of the IRC bridge with libera.chat for instance.
it’s funny because I’ve never experienced that in the XMPP world where the protocol is so stable that you can just S2S/C2S with decades-old servers seamlessly, whereas failing to update synapse for a matter of weeks guarantees compatibility issues. And I’m not even talking about 3rd party implementations like conduit for which incompatibilities is a guarantee.
Not to dismiss the work of FOSS developers, but siskin seems quite primitive. It does provide the very basic functionality that you could expect from any messenger from about 10 years ago but that’s about it.
I may try to take another look, but I did have a ejabberd server that was passing pretty much all the tests in the conversations suite, but I did not manage to make calls between pidgin and conversations.
Which is kind of my beef with frustration with XMPP. There was never a whole combination of client/servers that would work consistent.
As long as this working implementation is working and it is open source with some community oversight, I don’t mind having a clear leader in the project. The alternative is this eternal push-pull of forces that we had in XMPP, where we end up with a fragmented ecosystem which is never universally accessible.
Well, yeah… but since when it is a good idea to let a server unpatched/out-of-date in the public internet?
Fair, but it does that in ways that do not deceive its users, as in, what it does it does pretty well.
As far as I’m concerned, Instant messaging was a solved problem 20 years ago, we had practically more features in Yahoo and MSN Messengers (of which XMPP was a superset, for bridging and compatibility purposes), and Whatsapp, telegram and the rest have been removing the most distracting features. What are you missing for effective communication essentially?
Are you talking about
? As far as I remember, it’s pretty upfront about testing the capability but not the implementation (because testing for things like calls is very difficult and network dependent, you won’t get the same behavior from being behind a NAT or a public IP, and the test passing is no guarantee that it will work in the wild. Even 
is full of gotchas but is a good step to add to your testing).
There will never be a client nor a server that will implement all XEPs, because that’s not desirable: some fringe/IoT/obsolete cases just have no meaning nor use for most users, though there are some compatibility levels, updated regularly, that all maintained clients and developers target (e g. https://xmpp.org/extensions/xep-0479.html ). Under those circumstances you have a pretty good user experience.
But how about the implementation not working so well in practice and with enormous trade-offs, and the leader being essentially a marketing agency running for funds while covering up those trade-offs or blatantly lying about them?
Beyond the facade of new vector’s products, Matrix is as much fragmented if not more. Why would it be otherwise? Nothing is fundamentally better: there’s a spec and people chasing it. Except that in the case of Matrix, the spec is just there for reference and eventually consistent with what’s in the code of synapse running matrix.org, which is actually what matters (and might be quite different from what your server is doing for a bunch of good and bad reasons). I’ve bumped into more client to server and server to server incompatibilities hosting Matrix for few months than I did over years and years of operating XMPP. Things are just so much more stable and mature there (and slow, and boring, which users and admins alike tend to appreciate for something so central to their lives).
AFAIK, none of that existed 20 years ago and all of that are features that expected of any basic messenger.
GOTO 1. It’s the best one that we have (in practice) and it’s open source. If leadership ever becomes a real problem, it can be replaced.XMPP had that in 2002, before emojis was a thing outside japan :)
https://xmpp.org/extensions/xep-0038.html
2006: https://xmpp.org/extensions/xep-0201.html
2003: https://xmpp.org/extensions/xep-0080.html
2006 (see reactions)
Which media? You had whiteboards in 2001 (https://xmpp.org/extensions/xep-0010.html), games in 2002 (https://xmpp.org/extensions/xep-0047.html), stocks in 2003 (https://xmpp.org/extensions/xep-0067.html), rich text (beyond markup) in 2003 (https://xmpp.org/extensions/xep-0071.html), mood (https://xmpp.org/extensions/xep-0107.html), activity (https://xmpp.org/extensions/xep-0108.html), maps (https://xmpp.org/extensions/xep-0110.html), tune (https://xmpp.org/extensions/xep-0118.html), co-browsing (https://xmpp.org/extensions/xep-0151.html), calls (https://xmpp.org/extensions/xep-0166.html), serverless (https://xmpp.org/extensions/xep-0174.html)
and all those were added to XMPP because they were in widespread use in the popular messengers of that era (for the history lesson, XMPP was built first and foremost to bridge and unite all messengers). So, yeah, the trend has been going towards simplification over the years, not the opposite, and there were many many things that you could do in MSN Messenger in 2005 that you won’t be able to do in FB/WA/TG/Matrix/… :)
XMPP had all that, but there was no single application that implemented all of that. What we had was a hodge-podge of different applications, each trying to have their thing built into the standard but not really ever becoming an universal implementation. The fact that you can point to 11 (eleven!!) different XEPs as a response to “media embeds” should be a point of shame, not of pride.
I understand your defense of open standards and I’d love if the bazaar model could’ve worked for XMPP. Unfortunately, it didn’t. It is taking a Cathedral to come up and implement something that is at very least workable in all major platforms and still open for those that want to deviate from the main effort.
Is the Cathedral perfect? No, of course not. No institution ever is. But I can have my wife and my parents install Element on their phones (android or iOS) and be talking with them in less than 10 minutes, but I can not do the same with XMPP without having to accept a huge amount of compromises.
You seem to underestimate a lot the messaging landscape of back then :) It wasn’t a “XMPP thing” to implement those for laughs and giggles, it was the qualifying feature set of every popular app then, and XMPP clients like Gajim, Psi, Pidgin, … were competing against multi-protocol clients like Adium, Trillian, Telepathy, … and 3rd party ones (like aMSN, KMess, …) to implement the features of MSN, Yahoo, ICQ, … Yup, it was a zoo, but it was not XMPP’s. The only point of shame I see here is that we lost pretty much all the fun and innovation when everything became “mobile-first”.
I don’t think this analogy is relevant there, and I certainly don’t think that the multitude of XEPs I listed are evidence of XMPP being akin to a bazaar: the XMPP protocol is very lean and coherent, and kept that way by the XSF. Those XEPs were meant to document and standardize the practices of the time.
I have no idea what compromises you are talking about. I have SO, parents and many more, of all ages, abilities and systems having joined XMPP, with no difficulty whatsoever. The experience probably even is better here than on Matrix because not only can you generate invite links/qrcodes that contain a bootstrapped contacts list, there is also the option to discover contacts via mobile phone numbers (e.g. from quicksy.im, choegram) that comes handy in some contexts.
@u_tamtam @pezhore It’s not like XMPP doesn’t have issues. Finding a combination of clients and servers to get a coverage of the XEPs you want is quite an exercise. MUCs are painful, especially if you want to join from multiple clients. Cross-device trust between accounts for E2EE AFAIK still requires each device to trust all the other devices manually. Matrix has many more multimedia features.
True, but the problems you mention really are a thing of the past (I’d like to get your feedback after using latest versions of maintained clients), and message delivery across multiple devices and networks does, in my experience, work much more seamlessly and reliably than on Matrix (I mean, there must be a reason why google is using XMPP behind the hood to push every single notification on every single Android device on earth, right?).
And those are client/polish issues anyway, delivering messages at enormous scale has been a solved problem in XMPP for two decades, the protocol hasn’t changed, essentially, but Matrix still hasn’t found a solution to their self-inflicted problem: https://telegra.ph/why-not-matrix-08-07
XMPP - now that’s a name I haven’t heard in a long time. I thought the woke Google chat federation and subsequent drop pretty much killed it off - but I’m glad to be wrong.
Are there XMPP based group chat/Matrix/Discord alternatives?
There is whole social network built on top of it. https://movim.eu
XMPP itself is the alternative, and the client you use shapes the user experience. If you want something that’s comfortable for large chat rooms and dealing with a handful of them on desktop, gajim is hard to beat IMO, if you want something web, movim and conversejs are good alternatives :)
@pezhore @u_tamtam Your question may require a bit of specifying. Discord is a product and a platform. XMPP and Matrix are protocols. So, uh, it’s a bit like asking whether there are any SMTP or IMAP alternatives to Google Groups? There are *many* servers and clients and supporting bots and libraries that do many things. What specific things are you interested in, to narrow it down somewhat?
Well, I’m slight embarrassed. I think that was part of my confusion about Matrix - it seemed to me that it was both a protocol and a platform. That colored my memory of XMPP too. IIRC, Jabber was the client and protocol before the protocol was renamed to XMPP.
As for what I’m interested in - I’m not sure. I don’t really use discord save for a few Patreon follows; my friends use a group Signal chat. I think maybe I’m interested in recapturing the old IRC feeling of finding a chat room and just “hanging out”? I suppose I could always dig out my Irssi client config and just join Freenode again.
(Ye gods, wtf happened here to Freenode/Librachat?)
@pezhore The confusion is somewhat warranted, since matrix.org is the main/largest instance of Matrix the protocol, using Synapse the server, and having web access via Element the client.
For just text chat, anything will do. Matrix has the bonus of having a liberachat gateway, though it’s had issues recently.
But, the experience is somewhat different. [1/n]
@pezhore XMPP and IRC (to my knowledge, which very well may be outdated) are quite similar - you join a room from a client, you get a nickname, maybe a few lines of history, you chat, you close your client or lose connectivity, you don’t know anymore what’s happening there. You want to join from another client, that’s a separate session, with a different presence and name on the channel. Your clients don’t share history etc. [2/n]
@pezhore With Matrix, depending a bit on channel settings, your account joins the room and gets either all history or starting from the point of joining. And your account is in the channel. Regardless of what clients you use, and how many of them you use, and whether they’re online at the time or not, it’s your server keeping track of what’s going on in the channel, and keeping history of it, so you have one presence and same view regardless of type and count and connectivity of clients. [3/3]
That’s not true in the case of XMPP: upon reconnecting, any modern client will request from the server enough messages to recreate the missing history (of course it’s up to you/the client to put a limit to that if you want).
I think even IRC(v3) is taking that route.
The counter points on the site you posted are either completely expected or even desired properties of distributed systems (like not being able to force a delete or room closure on another server), or just problems with specific implementation details or insufficient clarity in the specs (like interop hickups or handling of media files). As far as I can tell nothing on the list is an “unfixable” protocol bug or core design flaw.
I agree that some are, and I think that the point being made in the article was that some of those properties might be surprising/deceiving for those who approach Matrix as another chat platform and not as a “distributed partially-replicated graph database”.
What I consider “unfixable” is the fact that we are 10 years into this now, and that nothing has improved substantially: I sent a message yesterday which took 10 hours to deliver, and an enormous amount of resources at that. Matrix isn’t ready for mass adoption, it is still not reliable, it broke on its promise to be the “protocols of all protocols” by failing to allocate the funds to maintain the bridge with the largest IRC network, and the developers don’t see the overwhelming complexity of it all as a bug, but as a feature. To me, it looks like Matrix will remain a mediocre platform for the general public, aka. those who want something fast and that just work and don’t care about “distributed partially-replicated graph database”.