It's a fantastic protocol because of how simple it is. It doesn't try to bake-in features beyond the most fundamental of getting a message from one person to ot

It's a fantastic protocol because of how simple it is. It doesn't try to bake-in features beyond the most fundamental of getting a message from one person to others. If you want want support for multiple clients you can have it, you just need to connect through a bouncer. I think some people see this as a cludge: if you can't use a piece of software effectively without additional software that's a sign that the original software is lacking. This is simply not true: what matters is how usable and reliable the end result is. It's not an argument to say that a setup being composed of multiple components makes it hard to set up, because there are ready-made solutions like IRCCloud around for people who aren't interested in doing it themselves. The fact that the setup is comprised of multiple pieces is only a testament to its versatility. You probably want a bouncer for your own usage so that you can use multiple devices and receive messages offline, but you don't need any of that for your bot running on your server, and because none of the multi-device functionality is baked into the protocol, your bot never has to worry about it. IRC lacks comprehensive presence signaling, and to the extent that this makes read receipts impossible it's a good thing. It has /away which is almost good enough, but lacks good support for being set automatically by clients. End-to-end ecnryption is becoming fashionable even on proprietary chat networks, and IRC lacks it, and that is a missing feature. The other main missing feature is federated identity, which no major network has. But apart from that IRC's only problems are where it has the same feature twice, or whan lack of cross-network standardization prevent clients from offering higher-level interfaces. Most networks support both SASL and NickServ, which have overlapping functionality. I don't think ChanServ is standardized, so clients are stuck with showing things like flags on channels and users, rather than presenting a "channel settings" menu. If ChanServ were standardized, clients could automatically configure private channels. For these few things that IRC (currently) lacks, it gives unparalleled customizability, compatability (I can connect to basically any other chat service like Facebook Messenger or Slack through IRC, but not the other way around), and respect for users' freedom (XMPP and others offer this too, but are smaller).