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.
Everything in this article is an offshoot of the overcomplicated spec.
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.
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.
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.
I am still aware of both protocols, I still don't like Matrix and think XMPP is "good enough", or at least the best choice. Having an opinion doesn't make me biased against one or the other.
Not being paid for the work on something doesn't imply no bias towards it.
> Having an opinion doesn't make me biased against one or the other.
It might: Confirmation bias
> 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.
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?
At the end of the day, the point is that XMPP was never trying to “win” against IRC, ICQ, AIM, Matrix, et al.
There's nobody to talk to because companies explicitly make it so, not because a protocol is better than another