> IIRC it was XML heavy. Everything was an XML file. Every message. I know XML will have it's fans but for an instant messaging app that create a hell of a lot of overhead.

The "overhead" is minimal, especially with the features XML brings. A message looks something like:

<message to="user@example.com" type="chat">
<body>Hello world</body>
</message>

In a world where people stream HD video over their mobile data connection without a thought, I'm pretty sure XML is not an issue. There are binary bindings (EXI), but they never really took off outside some niche IoT systems. It just hasn't been a problem. XMPP has even been deployed over unreliable high-latency HF radio links: https://www.isode.com/whitepapers/naval-xmpp-roadmap.html

> Joining to servers was a pain as well. XMPP was intended to be federated but in practice it didn't really work well.

The large active network of federating XMPP servers would disagree with you. E.g. https://blog.prosody.im/2020-retrospective/

> A large part of that reason was because XMPP described a base protocol but then different servers could support different extensions off that and if your server didn't support the same extensions then you couldn't join.

This isn't quite accurate. Every extension in XMPP is designed with backwards-compatibility in mind. Two servers not being able to federate is not really a thing - federation is in the base protocol. On top of the base protocol various things can be negotiated. None of these are mandatory. Two servers not being able to federate due to differing extensions is a myth.

> There was also a lack of decent clients for XMPP. To be fair, this isn't XMPP's fault but rather the lack of adoption. But because XMPP was something that Google or others would use as a base to build their own IM network from, all of the good XMPP clients were locked into specific networks rather than like with IRC or Matrix clients that are designed to run on any network.

For the record Google federated with the open XMPP network, and allowed third-party XMPP clients to connect. Other providers of XMPP were not so open (Facebook never federated, for example).

Opinions of what constitutes a "decent client" vary widely. Being an open ecosystem, XMPP has a wide and diverse range of clients, and many people quite happily use modern XMPP clients such as Conversations, for example.

The biggest problem is that most clients are "just" open-source projects backed by volunteer efforts. It's very hard to find real sustainability (e.g. funding) in open-source, let alone open decentralized ecosystems, so resources are more limited compared to proprietary competitors.

I wrote a bit about this at https://snikket.org/blog/products-vs-protocols/

> It was very much built by engineers for engineers rather than intended for your average nerd to set up a private servers.

I don't know which Haskell server this was (surprisingly), but I've been working on making XMPP server setup easier since starting the Prosody project back in 2008. More recently I'm also working on Snikket, which takes things to a whole new level - you can have a private XMPP server up in just a few minutes without any technical knowledge of XMPP: https://snikket.org/service/quickstart/