Today we have various “replacements” for IRC that solve a lot of IRC’s problems. There are closed source solutions like Slack and Hipchat, as well as open-source solutions like Let’s chat, Rocket.Chat, and Mattermost, that call themselves a replacement for IRC.

They not only provide persistent channels without netsplits, many of them added voice calls, the ability to upload files directly, the ability to use formatted texts, and a lot more. When Slack introduced threads for conversations inside a channel, many people called it the ultimate killer feature.

But let us look back into the “old world”. IRC. Simple text commands with a length of 512 bytes. Existing for 30 years now. Why is it still around? And why people still decide to use it?

It is not things haven’t changed over the years. There are different server implementations, which are so-called “services” added during the great IRC wars in the 90s, extensions added that are not mentioned by the RFC, and lots more.

But what stayed over all the time was the standard from 1993. The fact that it does not need more than a simple TCP socket and five commands to write a working IRC bot, the various client implementations that exist for all kind of platforms and allow everyone to connect to an IRC network in less than 5 seconds. No registration process with an e-mail, no broken layouts, just sending a TCP handshake, tell us what you want to be called and you are in.

That’s 100% KISS.

The power of netsplits

What looks like a big problem in first place, can be a real strength when you look at today’s problems: Netsplits.

Many people on IRC hate them. A netsplit happens, when two servers of an IRC network lose the connection for one or another reason. This means that users on these servers can’t communicate any more and will never see what the other side said while the servers were split.

The power of this is that servers basically don’t care about the network state, which makes IRC networks very scalable and easy to manage. Add a server, remove one, no problem.

Modern solutions like Mattermost, Slack, etc. have a database behind to keep the state of the application and don’t lose anything. But this creates big problems for scaling a network. The main question here is: How do you keep all sites (server locations) in sync? What happens if one goes down and you need to merge the histories later?

It creates a lot of headaches when you try to provide a multi-site HA setup.

Bring on your own client

While Rocket.Chat, Hipchat, etc. provide their own clients via a web interface, that’s usually not the case for IRC. And even today’s WebIRC (if we ignore IRCCloud) at the end of the day you only run a gateway server which then continues to speak the real IRC protocol with the server on a TCP socket.

Sounds like a problem in first place, but is another superpower. When I think about the time, since I use slack I had at least 2 times where slack had problems with their CDN and this way it wasn’t possible to use slack. Not even with a native client.

While when it comes to IRC you always have your native client talking directly to the target server. No CDN, no middle stations. Only your machine and the server. And when the server goes down, the networks usually have enough in their RR-DNS-entry so you are back online in a few seconds.

Conclusion

All in all, there is still no real replacement for IRC, because IRC not only provides an easy interface but also is super easy to scale and keep running.

I know multiple times that Slack and Mattermost instances went down, but can’t remember when entire Freenode was down. And for MadIRC I can date it to a day 2½ years ago when the entire network was running on a single Raspberry Pi and the SD-card died.

For me, IRC provides exactly what I need. Central networks with chat rooms about all kind of topics, very simple to use and clients for all kind of platforms. It simply works.

See you on IRC!