I've recently looked at the suite of protocols underlying RCS (or so at least I think; the standards landscape is as confusing as ever), and it's baffling how the industry ended up with that when XMPP was... just there.
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.
My family uses a self-hosted Prosody instance with the Conversations app on Android and Dino/Gajim on the desktop. It works great.
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...)
I love XMPP. The phrase "the gem of Instant Messaging" really resonates here. I run an ejabberd instance and it works great.
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.
These days I can't even use pidgin for xmpp, because the omemo plugin is too wonky. Now someone I'm sure will say I'm just holding it wrong and that may be so.. but I doesn't work for me despite trying for a reasonable amount of time to get it working.
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.
The problem here is that Pidgin's development didn't manage to keep up with the changing times. Stable branch is 10-15 years behind XMPP features. The developers are working on a Pidgin 3.0 (rewrite?) but that still has quite some way to go.
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.
> These days I can't even use pidgin for xmpp, because the omemo plugin is too wonky. Now someone I'm sure will say I'm just holding it wrong and that may be so.. but I doesn't work for me despite trying for a reasonable amount of time to get it working.
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.
We're still here and we're getting close to finally getting a pre alpha Pidgin 3 out the door. In the mean time check out https://pidgin.im/plugins for third party plugins that provide at least basic support most of the modern protocols.
Facebook via xmpp was the last thing Facebook was good for. It was nice to be able to strike up the occasional conversation with an old school friend or acquaintance. It really does feel like everyone is online more than ever yet somehow more isolated.
I can recommend beeper! I don't use it for encrypted messengers because I don't want to accidentally leak incoming messages that were sent with the expectation of e2ee.
But it's great for catching a few of the odd ones.
> A more rigid core standard, actively keeping up with new technology may have delivered XMPP’s federated dream. In reality, each sever supported a different feature set, while lacking common features every other chat app offered. As mobile technology transformed, XMPP stayed still. Pidgin worked on Google Talk, before an XEP brought (necessary) OIDC authentification and those 3rd-party clients couldn’t keep up.
But dominant doesn't mean it's the only one... most of my friends are on WhatsApp, but I use iMessage to talk to my wife (unless it's a group of friends then it's back to WhatsApp), apart from one or two friends who aren't o ln WhatsApp and then I use FB messenger... we have one gaming group with one guy not on FB and one guy not on WhatsApp, so I'm the meatware bridge between them.
I think the big issue with XMPP are the clients. Element is so much better that it's hard not to recommend Matrix to people despite its bloat and metadata leakage problems.
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.
I'm curious which apps you've tried and what the deficiencies are you find in them.
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'm trying to think of a way to add some value other than anecdotal disagreement, but I am just shocked at this statement because I can't think of a single piece of software I think Element is "better" than.
Slightly rambling partial agreement ahead, sorry, I struggle with how I feel about this and need to write something longer somewhere:
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.
Sure, Element syncs much faster than other clients (FluffyChat is unusable for Instant Messaging) but leaving the browser tab open still thrashes one CPU core.
I think its not only the clients...Rather its what the server side supports and to ensure clients align with that....And i think among a group of techy friends, well, they can coordinate the proper settings...but it becomes thorny when involving some not-techie buddies...Of course its possible, but, you know, the onboarding process is less than ideal. I say that not being an xmpp guru of coruse, so YMMV.
> 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. ;-)
If you want to onboard a group of people you don't point them at "XMPP" the technology. You point them at a service or product that is built on XMPP, like Snikket.
XMPP lost because the spec is overcomplicated and hard to implement. As a result, good clients never materialized and innovation was really hard to do.
Everything in this article is an offshoot of the overcomplicated spec.
Not sure I buy that explanation. More likely is thst there's too little business advantage to being compatible with others and too much business advantage to having people inside your own ecosystem. Simple as that. There's just very little motivation for compatibility between these systems unless you are open source.
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.
This. Thinking that the complexity of a spec is the primary obstacle to adoption seems logical at first. But it can't be true if you consider that the specs of all kinds of "foundational technologies" we use daily - HTML/CSS/JS/the DOM, IMAP, USB, IP, etc - are not just complicated but often downright messy, full of overengeneered, inconsistent or contradictory features.
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.
My frustration with "too complex" is high. Criticism in general often devolves to very broad heresay & un-backed opinions, but man, too complex is just one of the weakest by far at this.
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.
I've done a lot of work on XMPP related projects and some specs, and I'm not sure that this is true. I mean, it's definitely complicated, that part is true, but of course it is, it's a protocol and it's not more complicated than other specs as far as I can see. Not to mention that, like the various clients for different platforms that this article mentions, one of the big benefits of XMPP over other protocols is that it has libraries for every major platform, so most developers will never need to implement the spec.
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.
Matrix and XMPP operate in very different ways Matrix is a graph database synchronization protocol, whereas XMPP is event based.
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.
Based on my research, but no deep implementation experience with either:
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.
XMPP is nice, I like pidgin as a client. I'm not a fan of modern chat applications having such a focus on group messaging/channels; I miss IM-focused desktop messaging software. Unfortunately, getting people you know to actually USE your preferred chat software is more difficult than running an XMPP server. Often I've met people online or IRL and exchanged phone numbers with them only for them to ask to move to Discord, which I don't really like using.
Readit News
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.
https://xkcd.com/927/
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...)
[0] https://www.jwz.org/doc/cadt.html
https://archive.is/t5m32
The host, jwz.org, redirects traffic linked from HN.
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
[1]: https://github.com/jason-lang/jason
[2]: https://en.wikipedia.org/wiki/AgentSpeak
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.
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.
I no longer use Facebook Messenger, but I really miss the Steam plugin (its been busted for years at this point)
Now I have to use different apps for Signal, Element, Slack, Discord, WhatsApp, Telegram, ...
> A more rigid core standard, actively keeping up with new technology may have delivered XMPP’s federated dream. In reality, each sever supported a different feature set, while lacking common features every other chat app offered. As mobile technology transformed, XMPP stayed still. Pidgin worked on Google Talk, before an XEP brought (necessary) OIDC authentification and those 3rd-party clients couldn’t keep up.
And then I have people who only use Discord...
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 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.
> 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. ;-)
Everything in this article is an offshoot of the overcomplicated spec.
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
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.
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.
They have something in common though: not letting users communicate outside their own ecosystems.
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.
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.
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.
Yes, it's called "XMPP".
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.
The closest comparison is probably Matrix and that is a pretty complex protocol too.
Why bother to run a server or install a client if there's nobody to talk to?
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).