I think ‘steamrolled’ is a little strong. Slack is more or less a pretty design on otherwise old concepts and ideas. Not to trivialize that: it was despirately needed.
Really IRC just needs some well designed clients, I don’t like any of the offerings I’ve seen for iOS or desktop.
IRC is interesting, but it doesn't solve the use case by itself. (IE, as a user I can easily look back to the entire history of the channel regardless of when I joined and can search every message that was ever sent on the server - or every message in the last 12 months even.)
A set of RFCs isn't really in the same ballpark of the same planet of the same local galactic group as a mature product that I can go sign up for and be using in under a minute.
Maybe in a few years. I say maybe, because XMPP is an IETF RFC, and frankly, it sucks.
What do you not like about the protocol? Like everything, it has its warts, but having worked on a few more-or-less proprietary protocols XMPP is much better designed and thought out than most of them. The community has had a lot of time to address some of its flaws whereas Slack, Stride, et al. tend to reinvent the same problems XMPP solved 20 years ago.
Let me just start by saying that I'm a big fan of XMPP. I run my own server, and talked to my friends exclusively through XMPP until that fateful day that Google turned off federation support for Gmail chat, and I lost contact with a bunch of friends. I still run my own server, though I don't use it nearly as much as I used to.
XMPP is a well-thought-out protocol, and a lot of the XEPs are great features. The problem I always had with XMPP is that XEP support is unequally distributed among clients, and the fragmentation really undermines the amount of cool features XMPP has to offer. As a (made-up) example, Psi+ might support video calls, but not server-side history, and Pidgin only supports server-side history, and Adium is the only one that supports Service Discovery...if I want both, I have to pick a client, and possibly have to use two clients signed in with different resources.
As a possible solution, we could have a "logo program" for XMPP, where a core set of XEPs are required to call yourself an XMPP client (this is the case already IIRC), and you get rights to call yourself "supporting XMPP-Enhanced" if you support these other XEPs, and "supporting XMPP-Full" if you support all of these XEPs. Something like that might work, but you'd have to have a way to actually drive development toward these features.
I'm going to be pedantic here, but I think it's important to be precise: this is a problem with the public/federated XMPP network (let's call the network "Jabber", since some people use the term that way), not with XMPP (which is a network protocol that could be used by any number of services). That is to say, XMPP==HTTP, Slack==google.com.
XMPP could be used to build a service like Slack (with its own clients, specific feature set, etc.) that may or may not be federated and it would still have the benefits of using an open protocol (even if it's not federated I can use a more accessible client, a client on a platform they don't support, less work to get up and running because libraries exist, etc.)
I'm hoping the Compliance Suites will become something like you mentioned in the future, but I'm no longer the author so we'll see what the new authors do with it: https://xmpp.org/extensions/xep-0387.html
I thought about this too. My idea was to introduce some sort of version badges, like 'This client supports feature set 2018'. Every 2 to 3 years there should be new definition of which XEPs a client should support in order to be allowed to be called 'Supports feature set xxxx'.
That way you could very easily coordinate a common target for XEPs. Clients which would not support the newest features would still work with the others but users could simply see which clients support the state of the art features. And for developers it would make it easier to identify and skip old XEPs (e.g. how many XEPs are there to confirm a message has been received? Which is the recommended one for new implementations?).
