Because XMPP sucks. It had 20 years to succeed, and failed. Maybe it’s time for you to move on?
Last company I worked at that used it internally had thousands of employees in IT and still considered maintaining the jabber server not worth it - a million XEP extensions cannot bring it to the same level as a modern chat client. On every matrix post the xmpp crowd comes out of the woods, but what have you got to show? What’s the best cross-platform or web client for it right now? They all look like half-baked ports of long abandoned QT apps made for Linux and still don’t support syncing/multi-presence well.
Messaging underwent an earth-shattering paradigm shift in the past 20 years, so numerous features considered optional back in 2000 are now mandatory when you want any mass market appeal (which is the whole point when messaging is dominated by network effects).
A rework of the FOSS messaging ecosystem was much needed, and Matrix was the one to deliver it and not XMPP. I say the winner takes the crown, especially when the end result is more coherent for users.
The fact is that sometimes the kind of tool you need is a solid monolith built from the ground up with specific objectives in mind, and not a loose accretion of small utilities and extensions.
I wish Matrix delivered what it promised. But it hasn't yet.
Matrix is coherent if you use the reference server and clients. But so is XMPP if you get them from the same source. And the Matrix reference server needs pretty powerful hardware.
> And the Matrix reference server needs pretty powerful hardware.
That is not a bug, its a feature (or so the Matrix people say).
In fact, part of the Matrix design is a fat server which has a lot more responsibilities by default than an XMPP server. However, I guess a full-featured XMPP server (with MAM, Push, etc.) probably has similar requirements.
* Dendrite ("the rewrite") uses about 5-10x less RAM than Synapse; it's in relatively late beta and you can see for yourself today. For instance, dendrite.matrix.org is currently sitting at 480MB of RAM, despite being in ~5000 rooms spanning ~150K users.
* Matrix is coherent no matter what clients you use, given there is only one version of the spec (and as it happens, we haven't broken backwards compatibility yet). Sure, some implementations might not have implemented all the features, but the features they do implement (assuming they're not buggy) will work reliably with any other client or server out there.
It's fine to dislike Matrix and pine for XMPP, but please don't spread FUD.
The third party Matrix ecosystem is exactly as coherent as the XMPP ecosystem. Sure, some implementations might not have implemented all the XEPs, but the XEPs they do implement (assuming they're not buggy) will work reliably with any other client or server out there.
I'll like Matrix when it can replace XMPP. Dendrite sounds like a step in that direction when it's mature.
The difference is that there are multiple different XEPs performing similar operations, and even with the compliance suite XEPs, it can be confusing to synchronise on whether different bug-free clients are speaking the same dialect.
Whereas Matrix ensures that there is only ever one way of doing a given operation at any point, and those operations are backwards compatible, because there's only one spec. Obviously the client and server you're talking to needs to have actually correctly implemented the bits of the spec that you're trying to use - but there's no openpgp v. OMEMO or rival file transfer mechanisms etc. It's only a difference in governance, but it's an important one.
Obviously, a single monolithic spec controlled by a committee like the matrix spec core team has its own problems (most importantly, the committee can become a bottleneck); and we still provide mechanisms to let people experiment via the equivalent of vendor prefixing, which can go horribly wrong (c.f. aggregations in Matrix) if not managed with discipline.
But, I'm not trying to spread FUD about XMPP - just try to explain that the approaches taken are different, and have different tradeoffs, and are not "exactly the same".
> Matrix ensures that there is only ever one way of doing a given operation
That's not entirely true though. Press voice call in a client and you may end up with an embedded jitsi, some WebRTC thing, or nothing at all. That's exactly how xmpp clients started to diversify.
> I'm not trying to spread FUD about XMPP
Yeah, the tone could certainly be improved. Every time Matrix comes up, someone mentions xmpp and immediately the flinging starts about how broken it is and how those developers let it slide into obscurity.
Which there may be some truth to, but it really leaves a bitter taste. Especially since much of xmpp lives on in Matrix in bridges to other networks. Matrix really got a flying start there, and that's a good thing! Software should be shared and built on.
What worries me a little is that the same problems xmpp had, with protocol verbosity and problematic integration with smartphone platforms, is bascially the same in Matrix. The protocol is at least as verbose, and battery management is at least as hard. As a successor to xmpp, one might have expected to learn more from its problems. I'm certainly not complaining however, the more software the better, and the web client is very nice.
> That's not entirely true though. Press voice call in a client and you may end up with an embedded jitsi, some WebRTC thing, or nothing at all. That's exactly how xmpp clients started to diversify.
This really isn't an example of protocol fragmentation - it's behaving precisely as expected.
There is precisely one way to do a 1:1 VoIP/Video call in Matrix: https://matrix.org/docs/spec/client_server/r0.6.1#voice-over.... It hasn't actually changed since 2015 when we first added it to the spec, until recently when there's a proposal to improve it called MSC2746: https://github.com/matrix-org/matrix-doc/blob/dbkr/msc2746/p.... Now, this is a proposal to patch the spec - it's a Matrix Spec Change. It retains backwards compatibility with the current behaviour, and once the MSC is approved it'll be merged into the spec and the MSC will be discarded.
There is precisely one way currently to do VoIP/Video conferences in Matrix: you instantiate a 'widget', to embed whatever web conferencing service you like into your chat room (e.g. Jitsi). You use the widget API to control it. Widgets aren't actually merged into the spec yet, but are specified at MSC1236 (https://github.com/matrix-org/matrix-doc/issues/1236), which should get reviewed and merged in real soon now. So, as long as your client implements widgets, you can do conferences. In future, we have plans for native Matrix conferences (MSC2359), but this is vapourware.
Finally, if your client doesn't implement 1:1 and doesn't implement widgets (or if your don't have permission to perform them in that room) then obviously hitting the call button won't work. But that's hardly fragmentation; it's just incomplete implementations.
Now, if there were multiple competing ways of doing 1:1 calls, or of doing conferences flying around, I'd totally agree we were seeing XMPP-style fragmentation. But we're not, and if we did, we'd see that as a massive bug and jump on it to resolve the fork in the Matrix Spec Core Team, and ensure that matrix.org/docs/spec resolved the collision asap.
> Every time Matrix comes up, someone mentions xmpp and immediately the flinging starts about how broken it is and how those developers let it slide into obscurity.
Perhaps, but that's not me or the Matrix core team doing that (well, other than back in the very early days when I was still feeling a bit salty about XMPP). We can't control what randoms on the internet say though :|
> There is precisely one way to do a 1:1 VoIP/Video call in Matrix
Yeah, that's awfully close to what the xmpp people used to say. There are rtc calls and there are conferences, and otp is something else than omemo entirely.
For the end user however, when they click that telephone icon in their client, they may or may not get an embedded widget of some type or other, or an rtc stream, or something else. Should the remote client support the same thingamajig, they get a voice call. Look at the dozen or so most popular Matrix clients and for a non-technical user, it's still a gamble.
It's pretty much comparable to email in the 90s. Send a file, and it may end up as a uuencoded Mail Attachment, or perhaps a base64 encoded MIME. In the latter case it may be a multipart MIME or a non-multipart. Non-technical users sometimes couldn't open the file and then you had to send it some other way. Over time some clients got important enough for a de facto standard to emerge. It's still not perfect in 2021, one well known software company insists on their own .eml attachment that doesn't always work.
Matrix is quite similar to xmpp in this regard. Take the dozen most popular clients for each protocol, and check off how many popular features (voice calls, e2e, profiles, conferences, screen sharing etc.) interoperate fully. There's certainly room for improvement.
Don't take this the wrong way however! This is the price we pay for open protocols. If the alternative is low protocol innovation, then bring on the interop testing and annoyed users! It's worth it.
> aren't actually merged into the spec yet, but are specified at MSC1236
You even have standards proposals! They have numbers. Great! Let me guess, you bunch them up, spread some holy standardization water on them, recite an incantation and then they are part of an Offical Standard. Guess how many other protocols developers do that?
> that's not me or the Matrix core team doing that
Again, the tone could certainly be improved. One needs to look no further than this thread, to see other software developers being told in exactly how many ways their standard suck.
Take pride instead in what you did, and if someone asks you again why you didn't use the existing standard to build your chat product, just tell them you had more fun that way. Don't say inefficiency, don't say battery management, don't say interop when all of those metrics aren't looking any better in Matrix. Tell them about the nice team web chat you did, which is plenty reason to use it.
Most of the fragmentation in the XMPP ecosystem is just incomplete implementations.
> We can't control what randoms on the internet say though :|
You could acknowledge Matrix's shortcomings instead of denying or minimizing almost every criticism. And not say things like "It's fine to dislike Matrix and pine for XMPP, but please don't spread FUD."
> Obviously, a single monolithic spec controlled by a committee like the matrix spec core team has its own problems (most importantly, the committee can become a bottleneck); and we still provide mechanisms to let people experiment via the equivalent of vendor prefixing, which can go horribly wrong (c.f. aggregations in Matrix) if not managed with discipline.
...which is by far the biggest shortcoming of Matrix I'm aware of. I reserve the right to refute the inaccurate criticisms though (and to call them FUD, if that's what they are :)
The approaches are more similar than you think. At least the parts you mention Experimental XEPs let people experiment. The compliance suites provide a single spec controlled by a committee. And the differences don't matter when the user experience is the same.
XEP-0027 OpenPGP has been officially obsolete for Matrix's entire life. XEP-0374 OpenPGP never went past experimental. It was officially deferred 3 years ago. OMEMO is the only proposal active.
The compliance suites tell you what you need for file transfer. Core requires XEP-0363 for file upload. Advanced requires XEP-0234 and XEP-0261 for direct transfer. You can ignore the experiments.
Figuring out what features 2 clients share can be confusing with either protocol. Looking at Matrix's clients matrix[1] is easier than finding a list of XEPs for each client. But you still have to figure out what the server supports and what it doesn't have to.
The real difference is how 1 company dominates the Matrix ecosystem.
> Whereas Matrix ensures that there is only ever one way of doing a given operation at any point
I trust you that you mean what you say, but I wonder what an implementation would look like (from a user-perspective), that supports something like OpenPGP -> OTR -> Ratchet. I mean, upgrading security over time is mandatory and when I remember how it evolved for XMPP I clearly do not want an implementation that still has all the draw-backs that OTR had.
So I agree that XMPP is lacking some good governance, but I don't see the rivaling XEPs necessarily as the core problem, as many of them had quite some time between the drafts. The bigger issue is that many clients don't have enough developer momentum, so that XEPs that were drafted like 5 years ago are not implemented yet.
Regarding implementation bugs: I know XMPP has the compliance suite, but I feel like it doesn't catch bugs and is more of a basic testing for feature compatibility. Does Matrix have some kind of test suite, that simulates physical disconnects, package loss and the likes for testing real client and server implementations? I know that would not be an easy feat, but I wonder what the best way would be to build something like that, to improve the quality of the existing implementations.
OpenPGP could mean XEP-0374 which is newer than OTR. But XEP-0374 went from experimental to deferred 3 years ago. It isn't really competing with OMEMO.
XEP-0374 is very fresh compared to other PGP-related extensions. Just to give an example, 'XEP-0027: Current Jabber OpenPGP Usage' became active in 2002.
If it is competing with OMEMO or not might be a separate discussion, but both can be used to utilize E2E encryption of messages.
XEP-0027 became officially obsolete in 2014. I'm giving them the benefit of the doubt they didn't mean anyone has to think about XEP-0027 in 2021. They implied they could break compatibility some day. So I think they're talking about not having 2 current standards. How they see a transition working is still a good question though.
> Whereas Matrix ensures that there is only ever one way of doing a given operation at any point
Python used to claim the same thing when it was a fresh new language, as a reaction to Perl where the opposite was encouraged. Becoming mature and anchored in reality changed some of that.
Some implementations not implementing all the XEPs is exactly my point. "A Matrix server" / "a Matrix client" conveys an expectation that certain functionality will be included. Low-feature implementations will exist, but I assume it will be clear they serve a niche.
Synapse is the only fully featured server. Element Web/Desktop is the only fully featured client. Most of the other servers and clients are aiming for general use. They're just incomplete. Some of the niche implementations like weechat-matrix are in better shape actually.[1]
I've been wondering for a while how hard it would be to adapt Ejabberd into being a Matrix server implementation. Only a small part of Ejabberd is actually all that XMPP-specific.
YES! I never understand why people are so eager to defend XMPP for its so called perfection, when it's so bad in reality. The "eXtensible" part only is a huge and unfixable mistake. Make it feature complete, not eXtensible, or you end up with dozens of clients not working the same way and subtly failing in multiple scenarios.
IRC is lacking a ton of features. It doesn't even have a standardized charset! Nowadays people want E2E encryption, using multiple devices, multimedia, real-time audio + video, contact management, push notifications etc.
I use IRC. I use it with multiple devices, including desktop and phone. I have "contact management" and notifications (whatever push is) on both desktop and my phone. I use OTR for private messages. The only thing it may be missing is audio/video, but I think even that may be doable, I have not researched it due to lack of need.
I do not think so. I SSH into my Linux server where I run irssi (IRC client) inside screen (screen manager). Some people use IRCCloud. That is how I can use it on both my phone and desktop. On phone I use JuiceSSH, but I have used ConnectBot before, too.
I have notifications because my status bar and window manager know how to handle urgency hints and "bellIsUrgent" is set to true.
OTR is natively supported by irssi. Weechat supports it via a plugin. I do not know about other clients.
As for contact management... I am not entirely sure what it entails. Some IRC servers (such as UnrealIRCd, for example) support "WATCH" which is a notify-type system. The server will send you a message when any nickname in your watch list logs on or off. You can read about it more here, along with alternatives: https://ircv3.net/specs/core/monitor-3.2. There are a couple of different ways to achieve the same thing.
XMPP was pretty successful in the 2000s. More than Matrix so far. There were missed opportunities but the main reason it declined was Facebook and Google decided closed was more profitable than open.
"It has come to my attention that clients which we do not control connect to our service. This severely limits the monetization opportunities available to us. Please fix before it is caught in a due diligence."
Last company I worked at that used it internally had thousands of employees in IT and still considered maintaining the jabber server not worth it - a million XEP extensions cannot bring it to the same level as a modern chat client. On every matrix post the xmpp crowd comes out of the woods, but what have you got to show? What’s the best cross-platform or web client for it right now? They all look like half-baked ports of long abandoned QT apps made for Linux and still don’t support syncing/multi-presence well.