It's overwhelmingly more of an outsider talking point than an actual issue in practice. There's a category of people that just says any extensible protocol must fundamentally have massive amounts of incompatibility, and brings it up every chance they can... and while that is technically always possible, it only happens in practice if clients diverge greatly. XMPP clients mostly work together much better than Matrix clients, from what I've experienced, as long as they've been actively developed at some point in the last decade. Which is by far most clients in use.
For Matrix clients I'm given to understand the issue is the lack of XEP equivalents. Either your server(s) and clients are all on the latest available version or you're SOL.
This makes third party clients effectively impossible since every change is basically a breaking change and the client and server are tightly coupled.
XMPP took it a step further and has feature segmentation by defining XEPs. This is basic minimum for defining an extensible protocol for client-server communication and has been for decades (maybe it was a new idea when XMPP first started). Notably, browsers use this same thing with w3c specs, which is why they keep working too. If you don't have this feature segmentation and negotiation, you don't have a functional open source client-server protocol full-stop (looking at you Matrix).
I think what XMPP has gotten better at is doing like with w3c and setting baseline minimum features, which has allowed more standardization of clients.
Don't get me wrong, I have been hearing about XMPP forever, and I would love to have an opportunity to try it. Unfortunately it hasn't happened. I have been forced to use Slack, Discord, I have had opportunities to try Matrix, Zulip, of course I have been using IRC for a long time. But XMPP? I may have installed an app, but I haven't had an opportunity to actually use it. Is there a list of communities there?
Then about it being confusing: you're right, that's an outsider point. Because I haven't been able to try it (again nobody ever told me "oh, this project is on XMPP, you can go ask your question with this app/website"), but I have been genuinely interested in it, I ended up on the official pages.
- Check the RFC list: https://xmpp.org/rfcs/#6120. The first one is more than 200 pages, the second more than 100. There are 5 "basic RFCs" and 19 "further RFCs" (whatever "further" is supposed to mean). There is no way I will even open them all. Conclusion: I have no idea how XMPP works, except that there is XML in the mix and a whole bunch of stuff around.
- There is a "technical overview" here: https://xmpp.org/about/technology-overview/. I invite you to have a look at it. Apart from the fact that it seems to use "XMPP" and "Jabber" interchangeably (I think? I'm confused), it kind of loses me at "Jingle", which seems to be a "multimedia specification" (does that mean it's for video?), and has a bunch of implementations, like "pidgin". Isn't pidgin an XMPP client? Here it's under the Jingle section. And then there are extensions, with a whole section just for "Multi User Chats": so the default is that there are no groups, and if my client supports this extension and the server supports it, then I can join a group? I gave up at "PubSub", I did not even read anything from "BOSH".
As a person who wrote his own IRC client, contributed to Signal and looked into the Matrix protocol (which seems more complex than I am comfortable with), I must say that XMPP is in its very own league.
My conclusion with Matrix was that nobody would ever want to write it from scratch, so there has to be some kind of `libmatrix` on top of which people could build. Seems hard in practice because it feels like it keeps changing.
I don't know how fast XMPP is moving, but I would hope that it is now stable. Is there a libxmpp that contains all the necessary features to write a client? Not clear to me. It feels like it's still a complex ecosystem where it depends on the client, and on the server, and on what you want to do.
> XMPP clients mostly work together much better than Matrix clients, from what I've experienced
I can only take your word on it: I don't know a community that is on XMPP, so I haven't had a chance to try. Matrix has been frustrating, that I can say.
XMPP has had less allure as "the new thing" since it's been around for a very long time. It was _the_ chat protocol in the 2000s when it started, and all chat apps used it (when AOL Instant Messenger, Trilian, Purple, Yahoo, ICQ, etc all interoperated). Vendor lock in started taking off not long after though, so Facebook Messenger (also originally XMPP) stopped interoperating and went fully closed along with a number of others, and the ones that interoperated didn't shift business models and disappeared.
None of that means there's anything wrong with XMPP, it just means it's not in the public mind.
IRC has been getting the retro nostalgia kick start, and it briefly came back to attention when Slack started as "wrapper" of IRC. In my experience IRC channels are used by about 50% of open source projects, even though it's abysmal for access on mobile devices, very unfriendly for users, and extremely limited in functionality. About 50% of those have a bridge to Matrix so the mobile access is at least somewhat solved, and there are some more usable client options.
It seems because you haven't seen people already adopt it, you believe it must not be good. I'd encourage some basic research for your own benefit so you can see how XMPP is way easier to setup and maintain, far more efficient, and more capable than the oddly more commonly used Matrix/Element. In fact, between the organization issues of the last couple years, everyone finally getting fed up with Matrix being brittle, unmaintainable, and extremely inefficient to run on a server, I would expect Matrix support channels to drop off very rapidly over the next few years.
> It seems because you haven't seen people already adopt it, you believe it must not be good.
On the contrary, I have been hearing about it for so long, I believe there must be something there.
But maybe there is something fundamental in the fact that because it is actually interoperable, it's a lot harder for it to get traction. If a client gets a lot of traction, it probably quickly gets tempted to leave the interop world and do whatever they want (and lock the users in). In other words, XMPP sounds like a success story of diversity, but the cost of that is that normies don't even know what it is. Similar to Linux in a way: if someone gets interested in Linux, the next thing they see is a gazillion different distros and people arguing about them (disclaimer: I have been a Linux user for 15 years).
Matrix is different in the sense that it does not look like a success in terms of diversity. Matrix is pretty much Element. And Matrix seems to be about converting everybody to Matrix: I have seen bridges to IRC that made the IRC experience so bad that people would move to Matrix. Not because Matrix was necessarily better, but because Matrix was killing the IRC experience.
In a way, I find it interesting that those "interoperable protocols" (both Matrix and XMPP) are all for diversity, as long as it is their protocol. XMPP wrote a blog post about the EU Digital Markets Act, saying something along the lines of "the DMA is a good idea, the only thing that they miss is that they should force everybody to use our protocol, XMPP". Matrix has a similar stance: "we don't consider it interoperability if we can't make it work with our protocol, no matter how much we destroy the experience on the other platform". Because the end goal is not really interoperability: it's interoperability under their conditions.
> when AOL Instant Messenger, Trilian, Purple, Yahoo, ICQ, etc all interoperated
Sorry to remind you, but this never happened. AIM and ICQ eventually interoperate because they were owned by the same company at that point. There was never XMPP federation in the mix here.
Yea, it was really only ever "libpurple let you easily use them all in one app nearly transparently, and many people did". Many did use XMPP under the hood, but afaik almost literally none federated.
Matrix is seemingly trying to leverage that memory, but "there's a bridge bot somewhere that you can run somehow, with extremely widely varying quality / integration smoothness" is rather different.
Pidgin is a universal client that supports many protocols/networks including IRC, XMPP, and has additional third party plugins from stuff like Discord and Slack.
I don't disagree, but whether you're even aware of the XEPs and how it's presented to the user, is a critical factor in viewing it as "confusing".
Gaim for example only even tells you about XEPs if you dig into the server settings, and then it shows a very good job of listing all XEPs from either the server or client and noting which are supported by each in a table if you're far enough down the rabbithole that this info is useful. But for a regular user they just log in and it Just Works (tm).
Yes I agree, apps should never mentioned XEPs. Most devs have no reason to even know about them, why would a user case? Some apps are built by protocol nerds and they like seeing the list. Maybe very hidden is ok but in general not something any user cares about.
How would devs not have to know about them? Say I want to write an XMPP-enabled app, how do I do it? Are there XMPP libraries that already implement all the required need protocols?
If the answer to "it's confusing" is "there are apparently standardised sets", it sounds like it is, indeed, confusing :-).