For example, for some time now the XMPP Standards Foundation annually publishes the "compliance suites" which detail for developers what up-to-date implementations are expected to be supporting. We recently updated the xmpp.org website to automatically calculate and display the compliance status of every project.
This, for example, is not fragmentation: https://matthewwild.co.uk/uploads/screenshot-20230119-167413...
Monal's support for calls is in alpha builds, and they're hoping to release it in the coming months. Gajim (written in Python) is looking for someone to help them out with their audio/video call stack, which needs some attention.
Servers (as in, actual deployments) are monitored via https://compliance.conversations.im/ - which feeds into curated lists such as https://providers.xmpp.net/
It did. It was bigger and bigger mess, which feature in which client was supported by what server. I still remember how spotty basic stuff (nowadays) like "send file to someone" was.
And then corporations happened. There was a brief beautiful period of time where you could just put up your XMPP server and chat both with Google and Facebook users directly, but companies figured out closing down their gardens is more profitable and it was no longer the case
> but for some reason recent open messaging alternatives seem to decide to develop new protocols rather than build on top of XMPP.
Coz it is a fucking mess of XEPs spottily implemented between clients and servers, and not always that user friendly.
If you can control server, protocol and client you can just implement stuff. You don't need to make a spec, hope other people's client implement it, start using it in your server, and hope everyone else agrees on it too. And you can just deprecate stuff that turned out to not work well, or just need to be done differently.
Frankly, XEPs shouldn't exist. There should be just XMPP 1.0, 2.0, 3.0 etc. with maybe optional "XMPP voice comms", "XMPP video comms" pack of features (for those cases where full voice/video chat is not relevant).
You either implement all or are noncompliant, no more "well, you send a message but target client doesn't support this XEP, they get garbage"
I wrote a bit about this dichotomy in this blog post a couple of years ago: https://snikket.org/blog/products-vs-protocols/
I didn't say it but yes, the support for old version for some time would need to be a thing. But it should be defined (say "3 years for last minor release of every version") so it can be planned for
> While there are obviously limits to how far backwards compatibility should go, it doesn't make sense to deny users basic messaging just because their app doesn't implement calls for example. That would just cause a different set of frustrations.
As you clearly didn't bother to read before you answered, here is what I mentioned in comment you didn't bother to read before answering
> with maybe optional "XMPP voice comms", "XMPP video comms" pack of features (for those cases where full voice/video chat is not relevant).
I don't argue for single version, but to very small subset of featuresets instead of sea of XEPs
So you don't need feature matrix, you see "client supports XMPP 4.0", you know what will work and what will not.
I do like Rust development process - stuff gets added to experimental, lives and gets tried by actual users, gets feedback, gets changed and then lands in stable. So stuff looking good on paper but... not being good ends up quickly weeded out.
FWIW, the EU has passed the Digital Markers Act which requires big tech companies to open up their platform. It'll take a while before it takes effect, but unless Apple, Google, Meta and all others are going the very expensive "fine me and we'll see what happens" route, we should soon see movement towards an environment where different apps can talk to each other again.
The tech industry being what it is, there is no real standard for interoperability yet, though there is an IETF taskforce working on setting up a standard companies may follow: https://datatracker.ietf.org/wg/mimi/about/
This, critically, considers encrypted messages in a standard way so that we don't lose E2EE in the process.
https://www.beeper.com/ is promising. It's set of matrix bridge over 15 chat network or so.
Neat.
For instance, I remember hearing that Discord banned users who used alternative clients.
I am astonished by how well the Signal bridge works — everything works! Read indicators, threads, mentions, groups…so far I have it configured as a linked device to my phone, but you can also configure it as your primary device.
I really want to use the WhatsApp bridge, but that seems messier. I don’t want to install WhatsApp on my phone, so it requires running Android in a VM with a VoIP number, and apparnetly risks getting banned from WhatsApp.
I genuinely think the main reason there are no successful open-source chat apps is that XMPP dragged them all down.
XMPP is reasonably specifically a protocol for Instant Messaging. You can theoretically do whatever you want with it, and you can theoretically turn it into a mechanism for delivering social-networking style asynchronous messaging, but it doesn't necessarily bring a lot of value, and it makes a certain amount of fundamental architecture decisions that aren't necessarily the best for a social network.
I am interpreting your "recent open messaging alternatives" in the social network framework because my perception is the major ones you might be thinking about are those things, like Mastodon and such. I'm not aware of hot new open IM protocols that are just "old school" IM.
That seems to be what the parent commenter has in mind far more than Mastodon, at least to me.
Edit: At least in North America, can’t speak for the rest of the world.
The VoIP server software they use supports XMPP natively so your softphone on your PC is just a Jabber client, and (as far as I've been told) they use XMPP to sync between servers.
You've definitely used Cisco telephony kit, because you've definitely heard this tune: https://www.youtube.com/watch?v=pais41IW5dk
There never was meaningful money behind it. It seems the only way a protocol can ever grow today is by having for-profit companies sponsoring its development, doing the marketing, pushing it to individuals, companies and public services. That's not too hard to understand: at some point you need people working on it, and in a capitalistic society you need to pay them, and thus you need to somehow make money. Even with all the goodwill and proper licenses and all, you need massive humanpower.
Google, Whatsapp, Fcaebook all used a form of XMPP but never intended to propel it as a federated protocol, only for their own usage.
I remember how excited my boss, Andre, was when he discovered the Jabber protocol. He convinced Webb Interactive to spin off Jabber.com as a subsidiary, and I went with him. Our first space was the former office of Webb's chairman, with four of us in there. Later, when the company moved from Glenarm Street to Wynkoop Street, we had part of the floor above Webb's floor. I spent a lot of time working on the bridge from Jabber to ICQ, which was always kind of touchy. And we did have a nice booth at the O'Reilly Open Source Conference in Monterey.
Then came the dot-com crash, and Andre was forced to lay off a bunch of people, including me. He didn't want to do it; I think he was as much in tears as I was. Eventually, I understand, Jabber.com was bought by Cisco. And Webb Interactive eventually kind of sputtered out.
I had some rough times, but I'm doing a lot better now after a bunch of other job moves (not to mention a gender transition). Andre's got Ping Identity now, and he's finally having the kind of success he deserves.