Why do IRC servers not communicate with a standard protocol, and can we introduce a standard protocol to talk between them?
Having a multitude of custom S2S protocols was inevitable given how IRC networks ended up being controlled, and we won’t ever introduce a standardised S2S protocol.
Here’s why, and why that isn’t such a bad thing.
When you look across the wide variety of software that makes up IRC, you notice that clients connect in generally the same way. Sure, there are slightly different numerics and different features are supported, but it generally looks the same.
Then you run into S2S protocols, the communication that goes between IRC servers… and those differences become so wide that it’s almost impossible to reconcile them.
Why is there this difference between the client and server protocols? Plain and simple, there are a few reasons:
- Different S2S protocols achieve different design goals.
- Sticking to a standard protocol when everyone’s extending it in different ways is very difficult.
- There are (almost) no incentives to stick to a single, common S2S protocol.
Let’s break those down. First, the technical argument.
Different S2S Protocols, Different Design Goals
Just look at timestamp vs delay. There was an issue with how servers prevented nickname issues when reconnecting. The TimeStamp protocol solved this issue by conveying specific new types of information between servers, changing the server protocol. The Delay protocol solves it by introducing unified behaviour and not (really) modifying the protocol as much.
The two approaches are not interoperable, and a server implementing TS can’t talk to a delay server. There isn’t a convincing reason for each side to set down their pitchforks and come to a common agreement. This is part of the double-edged sword of IRC standards and specifications — because no single body controls IRC standards, people can extend it in any way they want. Because of that lack of control, we get issues like this that simply… don’t get resolved, and cause protocol fragmentation.
Extending S2S Protocols is Easy, Useful and Fun!
Extending the server-to-server protocol you use allows you to write new features. Being able to do this without having to ‘consult’ some central authority is nice in the eyes of server authors, makes things incredibly easy, and it’s always fun to write new features. Everything pushes server authors to just go and make those changes themselves.
With the client-to-server protocol, how much servers can change is limited by the pure torrent of other software on the receiving end. There’s gonna be thousands of different clients connecting, and you need to always make sure those clients can connect. However, servers? Everyone who runs networks today has total control over the server software used, and pretty well every network operator uses a single piece of server software across their whole stack.
Keeping track of every way other authors are extending the protocol is difficult. You practically need someone, like a standards body, to keep an eye on all the implementations and keep updating specs. However, we don’t have that for S2S. We haven’t had that for S2S for a long time. And most linking-capable servers extend and change their server protocols with almost every release.
People extend S2S protocols to enable new features. There’s no way to do this in a specified, unified way across the IRC ecosystem, so it’s not done in a specified, unified way.
Common Protocol? Nah, We’re Fine
What is the most important thing for IRC? The most important thing is that clients can connect to servers. That is something that’s required for IRC to work.
What’s used beyond the Client-Server protocol is totally unimportant. Clients don’t care whether the server they’re speaking to is communicating with other servers via Insp Spanning-Tree protocol, P10, TS6, or even some fancy new custom protocol (or fork of a protocol). If they can talk to it with the client-to-server protocol, they can connect and start chatting.
If server authors keep to a single standard server protocol, clients will be able to connect with the client protocol. If servers keep their own multitude of custom protocols… well, clients will still be able to connect with the client protocol. Because most networks already use just a single type of server across the whole net, there’s no incentive to stick to any sort of standard.
I’d argue that allowing this sort of disparity of S2S protocols is a good thing, because it allows experimentation that can better influence IRC as a whole. For instance, there’s the RobustIRC project, which is an experiment with a less-unreliable S2S protocol. As well, there’s jircd, a daemon that uses Raft consensus to do similar things. And my WiP dcmi protocol that aims to fix netsplits in a different way.
Clients can connect just fine to all of those above, because the client protocol isn’t affected in any way. These are just a few examples of server protocols that are completely different from those before it — maybe for the better, maybe for the worse.
IRC allows this experimentation by having a reasonably-stable client protocol which, in the end, means that the server protocol doesn’t matter. And that’s an awesome upside of IRC.
Integration! Or Not, That’s Scary
There is also the offer of better-integrating with Matrix and similar sorts of new overlay protocols. The main issue with that is that server-to-server protocols inherently convey a lot of trust. Having an S2S connection to a network means that you can do pretty well anything on that network.
Aside from reducing bandwidth, there’s no real reason to require having an S2S connection in order to integrate with a network. You can do everything you want to do by opening up a whole lot of client connections instead, one for each client that wants to connect.
As well, S2S protocols are a terrible jumping-off point for standardising communications with other external chat protocols. They’re not even standard within IRC itself, why would we standardise them for talking with outsiders? On the other hand, the client protocol is standard, and extensions are coming for dealing with issues like this.
It’s not pretty, but given all the other issues with standardising a S2S protocol, using the client protocol as the basis of these communications is probably the best we can do at this point.
Those are the main reasons I don’t see an S2S proto coming anytime soon. At all. Seriously, I don’t think it’ll be a thing now, or at any reasonable point in the future.
It requires server authors to give up too much in exchange for not enough. To get everyone to switch, there needs to be a concerted effort, and a concrete reason to do so.
Say that one of these experimental S2S protocols works out, and you get something that fixes netsplits. For good. You’re gonna have a gargantuan time getting everything to switch to your shiny new S2S protocol. And those old daemons? They don’t even have the development resources to switch if they wanted to (and a number of them probably don’t want to).
So, what will happen? Probably nothing. Everyone will continue making their own S2S protocols, bridges like Pylink/Janus, and life will continue on with a multitude of different behind-the-scenes protocols.
And I think that’s okay. Because the important thing — the client-to-server protocol — is getting the appropriate work in standardising it, in the form of the Modern docs, Defs, IRCv3 and other specs.