The main site https://xmpp.org/software/ lists lots of different options but I have no idea what core/advanced means and comparing all of these would take ages.
That software list, how it's done and how it's ranked is literally confirming my initial point of critique :D
Last time I tried out several chat clients, most of them were alpha software, had lots of bugs appearing in normal conversation flows, well, or were so broken that they broke compatibility in subminor version updates to their very same client apps.
I just wish there was some kind of ACID test suite for XMPP or something else to reproducibly validate spec compliance. Maybe a test server or similar as a reference implementation. This way client or server maintainers would have to run their programs against the official test server to increase their compliance stats.
This is exactly what the Compliance Suits are for, and the XMPP Software Fundation is taking care of telling all the clients what they misses directly on the official website, for example: https://xmpp.org/software/movim/
This should not be allowed.
You can't run scripts on all the XEPs declared, some of them are purely redaction or bound to specific UI/UX behaviors. This is based on trust that the developers actually implemented things as stated.
https://joinjabber.org/ is/was an attempt at something more user-focused. It is not linked to the XMPP Software Foundation. BTW, joining the XSF and participating in discussion around protocol evolution, communication strategy and these sort of things is free, and only requires asking for write permission on the XSF wiki to add an application page. Everything happens in the open (mailing lists, chat rooms). We value democratic processes.
Not sure about servers, but for clients there's Gajim, Dino, and Conversations. Not much else is super relevant these days. Profanity exists but is significantly worse than irssi or weechat despite looking superficially similar. Kaidan is a KDE/Qt alternative to Gajim but I'm not sure if it's usable yet. It may be worth switching when it's fleshed out to escape the bugs and slowness of the GTK-based clients.
[0]: https://snikket.org
The developer is very active in updating and maintaining the software (both client and server), and it already supports most of the XEPs.
It's open source and fully supports self-hosted as first class, but if you want to support the developer he offers a cloud hosting paid offering as well. There's a crossover offer with JMP.chat too. If you pay $5 upfront for your first month of JMP.chat, you can get a free cloud hosted Snikket server for it to be setup on. As long as you maintain at least one number with JMP.chat, you keep the server maintained. If you don't, you get a chance to migrate your data. The Snikket cloud server gives you an XMPP server admin account, and you can setup as many accounts as you want. The caveat is that Snikket implementation is optimized for <1000s of user accounts per server.
If the answer to "it's confusing" is "there are apparently standardised sets", it sounds like it is, indeed, confusing :-).
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.
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.
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.
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.
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.
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.
Whether or not those are being done well / compatibly / etc, no idea.