The client -> relay protocol for weechat relay is not the same as the client -> ircccloud protocol for irccloud, and both of those are _not_ IRC

All those clutches exist to support the deficiencies of IRC, which only proves the initial point: IRC in its current form doesn't do enough, and that's why Slack, with all of those features out-of-the-box, "won".

If you replace IRC with SMTP the story is very different. IRC has a lot of protocol problems but the biggest one was honestly just not having an IMAP equivalent. IRCCloud is just providing the complementary protocol to IRC. Its existence doesn't necessarily mean that IRC is a bad transport protocol.

IRC has no message storage - so not only it has no IMAP, it has no POP3 either.

And IRC is a horrible transport protocol because it handles errors by dropping messages. SMTP has both message-ids and explicit confirmation response to make sure that as long as server comes up, eventually, the message will be delivered exactly once. IRC does not; so it is simply not appropriate for the cases where each message matters.

What I was eluding to was that irc (as a server to server protocol) is fine. As a client it has deficits but those are quite literally smoothed over by websocket capable bouncers and weechat relay.

IRC The protocol is not competing with slack. The IRC ecosystem is. And yes, it lost.

You might actually be right, server-to-server IRC is good for finding an efficient path between all the servers in the network (ie it considers the network as a whole, not just a series of 1-to-1 connections) and send the minimum information required, so we should be able to keep that and make the client-to-server protocol different.

In short, make the relay/bouncer part of the server itself, and tell clients to connect with the relay protocol, not the IRC protocol. If there were some common standard for this second part that would actually be a great thing.