Comment by WD-42
8 days ago
I’ve been running a matrix server for about 2 years for family. It’s… ok. Clients are bad. Right now nobody on iOS can send images because there is a bug in fluffychat preventing it. Kinda defeats the purpose of a chat for sharing baby pictures. Synapse is a beast. It’s basically taken over my entire VPS.
Joining rooms of various FOSS projects has been nice, but honestly I wish they’d all just stick to libera.chat
This article makes me wonder why we collectively ditched xmpp for matrix when it seems like the protocol is still miles ahead?
I am genuinely interested in hearing why we collectively ditched XMPP. I would love to hear someone who has been in the weeds on the development or even just following closely.
Edit: Seems someone beat me to it with a good reply.
> I am genuinely interested in hearing why we collectively ditched XMPP
We didn't. It was never very popular, and is today more popular that it has ever been.
It wasn’t popular? I remember using pidgin to talk to friends on google chat, facebook and my work contacts. It was glorious.
I haven’t had a reason to use an xmpp client in over a decade.
4 replies →
Depends if you mean just the technology or using it in the small federated spirit. Google Talk and Facebook Messenger were XMPP all the way through and worked with vanilla XMPP clients. Slack wasn't XMPP but supported it via a gateway until it was dropped.
Not sure how popular the small federation was back then, but I know Mac OS X Server touted an XMPP server and that was a first-class feature of iChat.
4 replies →
XMPP had rather bad name. Well-known design issues causing message losses, fractioned ecosystem due to varying implementation of extensions, unsuitability for mobile clients, absence of synchronization between clients, absence of end-to-end encryption. Most of these issues were (much) later fixed by extensions, but Matrix (or Signal for those who do not require federated one) was already there, offering E2EE by default.
Even today, E2EE in XMPP is rather inconvenient compared to Matrix due to absence of chain-of-trust in key management.
Sometimes I wonder if the endgame is each person having their own XMPP server for their set of devices. S2S is your E2EE then. Your chain of trust is your existing CA, unlike Matrix which starts from scratch. Cause XMPP wasn't designed from the start for clients not to trust servers, plus the fragmentation of C2S extensions was always a pain.
It's not a bad solution if someone can make it easy, even if it's a managed service that just lets tech-savvy users export it to self-hosting if they want.
Google Talk support for XMPP: 2005-2013
Facebook Messenger support for XMPP: 2010-2015
Jabber.org support for new accounts: 1999-2013
First-class integration with two of the world's largest social networks put XMPP in practically everyone's hands for a time, but when all the major hosts left, network discoverability and typical account longevity dropped drastically. The landscape is bleak today.
And since then, our collective needs and expectations of a chat platform have expanded. XEPs have been developed to bolt much of that functionality onto the base protocol, but that has led to a fragmentation problem on top of the bleak server landscape.
This unfortunate situation might be navigable by a typical HN user, and perhaps we could guide a few friends and family members and promise to keep a server running for them, but I think the chances of most people succeeding with it are pretty slim today.
Facebook never had "first-class integration". It was just a client bridge - you could login into Facebook Chat using your XMPP client, but it was a completely separate network, unlike Google Talk which was an actual federating XMPP server.
3 replies →
Decent overview (& more broadly but the heart is about XMPP & good ol’ capitalist corpo greed): https://ploum.net/2023-06-23-how-to-kill-decentralised-netwo...
We didn't. Big tech did, as XMPP broke down barriers so they lost their moats.
I.e. it worked too well.
> Clients are bad.
Yep. A friend ran an XMPP server for a while and the one person on iOS had a client that couldn't handle whatever encryption protocols the Android client supported, and the iOS client also choked on new certificates for the same domain (there was some way to accept it but the default behaviour was to just stop receiving). The killer that moved us to Signal was that someone got a new phone (something that had happened before without causing an issue) and the new phone could connect to channels but just saw nothing.
[dead]
> Two XMPP clients might support completely different feature sets.
This is of course true of Matrix as well. Just because you document everything in one place doesn't mean every app will support it all. Or that every app will even want to support it all. If every app were exactly the same there would be no point in having multiple apps, after all.
> The network effects of WhatsApp/Signal/iMessage are the real enemy, not protocol design.
Absolutely.
Don't know if it's still this way, but I had the exact same experience with the XEPs a decade ago. Even message history is an extension, but at least it has broad support. File transfer was much harder to get right.
The servers (ejabberd included) also all defaulted to a simpler but less secure config, so I would've appreciated a writeup like this post back then.