Overall, the impressions expressed in that comment from 2011 were relevant at the time, back when "Compliance Suites" specifications were not a thing and there

Overall, the impressions expressed in that comment from 2011 were relevant at the time, back when "Compliance Suites" specifications were not a thing and there was a lot more room for interpretation in many specifications. The situation has much improved since then. To reply to individual bits from that comment: > It has never seen serious adoption because nobody wants to touch it - and for good reasons. That's outright false. There's many successful commercial products using XMPP right now (eg. WhatsApp/Zoom or games and gaming systems like Fortnite, Origin, League of Legends) including for non-IM usecases (Google Cloud Print, Firebase Cloud Messaging, Nintendo Switch, Apple's push notifications). In the free-software world, there's actively maintained featureful clients (gajim/dino on desktop and snikket family of clients on mobile) and servers (ejabberd/proosdy/tigase). I can't say there's no bugs but i can say with confidence they're actively being hunted down. > It leads to ridiculous overengineering through layered complexity. Layering complexity may sound like engineering, but that's where the "eXtensible" promise of XMPP comes from. The same goes with Matrix/ActivityPub protocol: there's a reason people are doing it this way, and that reason is not "overengineering". > Take a lesson from IRC, a group-chat protocol that, despite its age, works and scales amazingly well. The protocol works remarkably well because it's dead simple. However, implementing a decent client/server that plays well with others is not easy (see IRCv4 debates) and each server in practice operates differently, more so even than XMPP servers. > It wouldn't take much fix the warts on IRC and extend it to cover everything that XMPP tries to do. Please by all means try. It'll take you far more time to design, and you can be 100% sure you're going to break many existing clients and servers by extending the IRC protocol. XMPP/Matrix clients on the other hand can handle missing features gracefully because the protocol is namespace'd/schema'd properly. I appreciate that concern for fighting NIH and that's a criticism i've addressed to the Matrix project myself, that it could have been implemented on top of existing XMPP clients and servers with two simple XEPs: one for decentralized chatrooms and state resolution, the other for client-to-server JSON API. But when comparing those newer federated protocols with IRC, i think the comparison has no grounds. Let me know if you're not convinced by these answers or have more questions.