> it's also much less reliable.

The software, or the service? Because IRC is not typically associated with tremendous reliab...*

* User has quit due to excess flood

Both. "User has quit" doesn't seem to happen in Slack, because Slack doesn't report stuff like that. But the problem goes deeper - Slack often fails at very basic functionality, like failing deliver messages until much later or duplicating them. It's helloworldware with a lot of marketing money to pretend to be a technically sound solution.

Why isn't IRC much more popular?

Because it turns out to be a colossally chatty and stateful protocol in an era of stateless mobile devices. Plus it's not HTTP... the rule at the network layer these days is basically "80 and 443 are open; every other port is good-luck-to-you."

OP's assertions it was more reliable are assuming a very static network. Modern protocols (Slack included) are far, far more reliable on a highly-unreliable transport layer.

Not true. Or rather: in theory what you are saying would be true, however in case of Slack it simply doesn't work: Slack handles unreliable transport worse than IRC - IRC never dropped or duplicated messages; you could reconnect to IRC client under a tmux session from anywhere and it would do the right thing.

> you could reconnect to IRC client under a tmux session from anywhere

That would actually be a pretty decent solution if it could be automated on a mobile device: run the IRC client in the cloud and then have tmux auto-reestablish every time it gets its connection dropped while the mobile device moves around.

I'd have to see it in action to be confident that a continuously-dropping-and-reestablishing tmux won't drop incoming messages or double-send though.

People (like me) have been doing this for over two decades now. It's quite well tested :-)

Excellent! Do you have a link to a write-up on how to set it up?

No business model, I think - and thus no money for infrastructure, further r&d, and marketing.