Eventually, the community just walked away, to IM systems that actually work somewhat reliably.
This is how XMPP fell into irrelevance.
"Flag days" in a decentralized network have to be used with caution. Ask whether it's better to communicate without a specific feature, or whether it's better to split the network into fragments which are unable to communicate with each other. The former is almost always preferable, however we used the "flag day" approach for mandatory server-to-server TLS, for example (which actually isolated Google Talk from the main network).
As for acks, those were first defined in 2004, and have generally been implemented since the beginning in clients that need it (e.g. mobile clients, and every client since WiFi and laptops became ubiquitous).
I can think of a number of reasons that XMPP is often overlooked when it comes to modern IM, but this is a weirdly specific thing to pick out, especially when I can hardly remember a time it wasn't implemented everywhere.
JMP/Snikket for tying a normal phone number to your XMPP @ are really convenient, but the clients remain a problem. Plus, SIP dialers are not supported on IOS afaik.
I am really surprised there isn't a venture backed company pushing XMPP forward. Maybe people have tried and realized it's not viable.
There are a number of companies in the ecosystem. Most have chosen not to pursue VC money in order to keep things going much longer. While a venture backed company can have success, most flame out eventually in my observation.
> I am really surprised there isn't a venture backed company pushing XMPP forward. Maybe people have tried and realized it's not viable.
Actually, WhatsApp would fulfill your definition there. They are/were a startup whose entire product/platform is an xmpp client (using their centralized server/instance). Now, whether they pushed "xmpp forward", or merely would be considered pushing a chat platform and who cares whats under the covers...well, that i leave as an exercise for you or others to decide/opine. ;-)
I think there's a tendency to dismiss this argument in the XMPP community (but there's a lot of truth to it, I choose to use the XMPP desktop clients but none of them are as nice to use as any big commercial IM providers client), but also a tendency for people to make this argument without realizing that they're comparing open source projects run by one or two people to VC funded projects with a company backing them. Of course Discord or Element or whatever will be "better" in some ways, they have a team and millions of VC funding behind them. However, one of the many reasons I chose to use XMPP back in the day when I was first evaluating whether to use it or Matrix, and one of the big reasons I got more heavily involved in the community later, was specifically because the standards body wasn't strictly tied to a company looking for VC funding (and all the individual client/server projects I've contributed to are the same). But, this does mean there aren't really any clients that I'm in love with (but there are clients for every random niche platform imaginable, which I think is probably more important personally).
All that being said, try Snikket if you haven't. It's relatively new, but I think they're really doing a good job of creating a suite of clients that can be recommended to "normies" who don't want to sacrifice shiny graphics for the sake of using something that's a bit more free from VC influence.
For anybody who wants to see a random interesting (well, interesting to some) application of XMPP, I recently put together a small demo of using XMPP with Jason[1] to connect AgentSpeak[2] agents to chat.
https://github.com/jason-lang/jason/discussions/118
Due to the lack of anyone to chat with on XMPP, I can't really speak to the day-to-day usability unfortunately...
Everything in this article is an offshoot of the overcomplicated spec.
Yes, it's called "XMPP".
Let's use group chats as an example: with Matrix if you join a group chat hosted on another server, the entire history of the chat gets synced to your server. This means it's very resource intensive to scale, but very reliable since you pretty much always have chat history available and if one server goes offline you can keep the group chat alive on one of the other servers (let's ignore netsplit style concerns for now, it's not really relevant to the high-level nature of the question). XMPP on the other hand is event based, this makes it much less resource intensive, but means that if the server you're trying to communicate goes down you don't have access to that chat room anymore (some servers mitigate this by using traditional high-availability techniques like clustering, but that's not really a protocol thing, I'm sure some Matrix servers also do clustering as part of their scaling strategy).
As far as features specifically related to IM, both support most of the same things, it's just a question of whether clients have implemented them or not in either protocol.
> with Matrix if you join a group chat hosted on another server, the entire history of the chat gets synced to your server.
This is not true. By default most Matrix implementations sync the last 20 messages in a room when a server joins that room, pulling in other messages only on demand if a user back-paginates the room. Room state (i.e. key-value metadata about the room) also no longer gets synced in atomically at join - instead it gets pulled in in the background (so-called 'faster joins': https://element-hq.github.io/synapse/latest/development/syna...).
XMPP continues to advance, so could be considered modern if you use the latest versions.
Matrix is more of an event sync protocol, consisting of a server to server sync protocol and a client to server protocol (sort of like email). It is mostly used for chat, but appears to be more flexible. Matrix uses JSON and HTTP.
XMPP is focused on chatmessages. In many ways XMPP and Matrix are similar. XMPP is based on XML and originally used TCP as the transport protocol, but has been extended to use HTTP now as well.
EDIT: I think a clearer way to describe the basic difference is that Matrix syncs Matrix Events across servers, whereas XMPP facilitates exchanging messages with clients. Most folks use the protocols to exchange chat messages. It is the way this is accomplished by the corresponding servers that differs significantly.
Why bother to run a server or install a client if there's nobody to talk to?
At the end of the day, the point is that XMPP was never trying to “win” against IRC, ICQ, AIM, Matrix, et al.
I'd argue that the "beauty" or "ugliness" of a spec can make the life of the particular programmer who has to implement it slightly easier or harder - but it has very little effect on whether it is implemented or not. That's a product decision which follows completely different considerations.
Back in the 2011 timeline, I printed and read the spec front-to-back to implement what was effectively an "early Microsoft Teams" (a real-time, chat-oriented client connected to SharePoint)[0] using XMPP.
The spec is very easy to read, understand, and implement.
I think on top of your points (and maybe adjacent or extended from that point) is that I think some entities like Google were probably seeking more wire efficiency over the XMPP protocol and possibly wanted to innovate/iterate faster. There was a wave of "real-time" collaborative apps at that time and I can appreciate the need for teams to innovate faster.
[0] Short video: https://www.youtube.com/watch?v=WG_W0VxjzbM
Few people have spent the time to get to know a protocol or system well enough to know what really was unnecessary or bad. The ability to crash out & then talk smack is high. Most haters haven't even earned that right!
XMPP is pretty simple to get started with. Theres not that many extensions you "really should have". The extension model let them grow & adapt well over time, giving more weight to the underlying eXtensibility model. I tend to agree it was mainly a push for privatization & lack of interest in economic mutualism that lead to drift away from XMPP.
TL;DR most people don't implement HTTP when they want to make a request, they add a dependency on whatever their languages HTTP library is. XMPP is the same.
They have something in common though: not letting users communicate outside their own ecosystems.
The closest comparison is probably Matrix and that is a pretty complex protocol too.
My point is, this argument is a bad one as it expects people to get the protocols right on the first try and that's never going to happen.
Now I have to use different apps for Signal, Element, Slack, Discord, WhatsApp, Telegram, ...
Disclaimer: I'm Aine of etke.cc, and MDAD is our project
And regarding other protocols I'm too scared these days. Every company is running algorithms looking for deviants to perma-shadow-ban and I just can't risk something like that.
Unfortunately Pidgin was one of the most popular ways to use XMPP back in the day, and this had a knock-on effect on XMPP's reputation as an out-of-date technology. People still install Pidgin today and tell me, yep, XMPP hasn't changed since 2006. Which couldn't be further from the truth.
You're Facebook. You want to provide an instant messenger you can iterate on quickly. You can put the work into making it XMPP-shaped and working with the community (whatever they means... Are you going to slip ship targets because Pidgin doesn't work as a client for your implementation?). Or you can just write and ship your own service and client at your own pace and not care about any other developer's needs or wants because you're trying to serve Facebook users, not developers.
It's true Pidgin 2's XMPP support sucks, there's no denying that. That said we can't easily fix that with the current API which is why Pidgin3/Purple3 is the only path forward.
That said, I'm pushing to have an experimental release of Pidgin 3 out by the end of the year. However it's only going to have IRC support right now because well there's only so many hours in the day especially when Open Source is your passion project and not your day job.
The libpurple (library behind Pidgin) support for xmpp is quite mediocre so it's not that you're holding it wrong.
Dino is great on Linux. There's an unofficial windows build that might or might not work. If it doesn't, then Gajim is "fine." Conversations is great on Android. I think Monal is the current best on iPhone, but I don't own an iPhone.
And the need for the existence of the above paragraph is, IMO, a big part of why XMPP isn't used. Nobody knows which clients to use, and the experience if you use an out-of-date client is terrible (seriously, emojis don't work between Psi (which is still listed on xmpp.org as a client, and was a great client 15 years ago) and Dino.
And then I have people who only use Discord...
As shown in a more visual way: https://xkcd.com/1810/
It often does. Check out these statistics:
https://www.statista.com/statistics/1311229/whatsapp-usage-m...
This is likely a huge underestimate too. They put UK at 71% but in practice it's used by everyone. You'd be a weirdo not to have WhatsApp in the UK, like not owning a smartphone.
I no longer use Facebook Messenger, but I really miss the Steam plugin (its been busted for years at this point)
One of those is not like the others...
The contortions they had to do to cram server-based federated instant messaging into the context of the SIP protocol stack by sheer force are something to behold.
I can only assume this is entirely by design – the more needless complexity, the more opportunity to patent things (or at least keep competitors out): As far as I understand it, practically all carriers are just outsourcing the entire thing to Google.
So, it's not such a gem?
It is, gods make it stop.
"Oh no complicated specification" do you think you're getting paid 100k/year because it's _easy_? Gods.
Sorry for the question but i don't really understand what this means?
[email protected]
"Hey, I want to set up a modern messenger."
"Sure! Here's XMPP, the ten extensions you need to enable and configure (problem left as an exercise for the reader), and the seven ports you need to open!"
"... Okay? A Matrix node is apparently a drop-in solution; I'm gonna use that."
XMPP is in desperate need of a Docker image that Just Works and the wizard to set up that Docker image. And then you need users savvy enough to have their clients configured correctly.
Matrix servers? You have mostly one implementation to choose from and it comes "packaged" as a monster container with several python modules likely already with CVEs and god knows what else. And then the resource usage...
Or install something that comes set up the way you probably wanted and never think about it again. Just docker and poof. Like Snikket
If I can make time again, I'll give that a look!
To my knowledge it had most of these things before any other chat protocol was widespread and prior to the great silo-ing.
Combined with JMP.chat, we even get SMS and voice calls from the telephone network to all our different XMPP apps. Truly feels like the future.
The technology of yesteryear seems to have more staying power. The protocols churned out by my generation seem destined for either VC/advertisement capture or death by CADT [0]. Maybe with the exception of Signal (so far...)
The host, jwz.org, redirects traffic linked from HN.
This aside, it is much easier to integrate than matrix, things like web hook is just a POST request to /api/send_message...
I think it would take off again with a nice crossplatform client with a discord like interface. But that would be expensive to develop.
For example, I'm writing this post with `vim` using `slrn` news reader, which uses a bridge that translates HN to NNTP (and vice versa).
Nostr is great because it doesn't tie your user name to some domain name that you don't own (like ActivityPub/Fediverse does). If a domain name is part of a user name, that ultimate gives "control" over your identity to someone else...(unless you're hosting your own domain, of course)
I think XMPP is probably the superior protocol (better than both Fediverse, and Nostr, and I've written implementations in both), for some technical reasons, but as far as I know it takes way more than 20 lines of code to implement a read/write operation, so imo it's too complicated.
Even ActivityPub looks simple at a first pass, but if you try to write your own server (like I did) you realize the protocol is a complete mess and compatibility issues are rampant across different sever implementations as a result.
It can't be fixed. It's dead. Matrix is the modern replacement.
I used XMPP to implement a chat client within our application around 2012. It was a freaking nightmare. The roster system, the incompatibilities, the lack of standardized synchronization, the never-working group messaging.
Lots of good XMPP implementations disprove this.
I hope Matrix just goes away and stops distracting the FOSS community from improving existing internet standards instead of custom protocols by random startups :)
A list, please. For iOS, Android, macOS, Windows.
> I hope Matrix just goes away and stops distracting the FOSS community from improving existing internet standards instead of custom protocols by random startups :)
XMPP had its chance, it blew it.
It's not like Matrix is killing it.
It's not exactly a new protocol, yet still feels like it's in the pre-alpha stage. Both protocol and the client/server software.
There have been revival/popularization attempts, but nowadays traction seems to be with Matrix.
Unfortunately that spec also has big issues and the ecosystem is still struggling with usability (though it has improved a lot recently) and implementations.
It’s an unfortunate situation in a time in which an open communication standard is more important than ever.