Understanding IRC Network Topography

The IRC protocol dictates that IRC networks are arranged as a star network. As such, there is only ever one path from any point in the network to another. Messages are “relayed” along this network via the most direct path according to the current connections between the servers.

Hubs and Leafs

In IRC terminology, a hub is a server to which multiple other servers may be connected, and a leaf is a server which serves many clients, while only connecting to a single other server, a “hub” server. Hub servers in turn have multiple leafs connected to them, and they may also be connected to other hubs. Hubs may also accept client connections, or they may be “dedicated or even “hidden” hubs, which only serve other servers on the network.

The IRC protocol forbids multiple paths between servers - so a server which already has a link to the network cannot establish a link to a different location on the network without breaking it’s existing connection - there are no redundant paths allowed.

Splits and Bursts

Breaking the links between servers, whether intentionally or unintentionally, causes an event called a “netsplit”, in which the network is temporarily fragmented into two smaller networks on either side of the broken link. When this happens, from the perspective of one side of the split, the users on the other side are seen to have disconnected from the network, with the split as the reason for the disconnect. Netsplits are usually brief events, as the servers are normally configured to automatically seek a working connection to the network, and IRC operators may also attempt to manually intervene by ordering two servers on opposite sides of the split to connect to one another.

Rejoining the two sides of a split network happens in a process known as a “netburst”, so named because of the burst of traffic as the two sides of the split have to resynchronize with one another. During the burst, information about the servers, users, and channels on each side must be exchanged with the other side, and information about the users and channels must be relayed to affected clients. At the same time, any “collisions” of unique names must also be resolved.

Nickname collisions

In a nickname collision, two users on opposite sides of a network have the same nickname at the time the parts of the network are rejoined. By default, under the original IRC protocol, this resulted in both users being booted off the network by a server-initiated KILL event.

As this is very disruptive, and invited abuse, several different ways of dealing with nickname collisions more gracefully have been devised. TS, or timestamp rules allow the user who has been connected longest to keep their nickname and connection to the network, while forcibly removing the newer user. Nick delay “caches” nicknames that were last seen on the other side of a split network until the server on which they were last seen reappears, or a delay period expires, and prevents the use of those nicknames, therefore removing, or at least significantly reducing the possibility of a collision. UIDs and automatic renaming provide a less disruptive experience for the user(s) on the losing end of a nickname collision, by having a unique ID used for routing messages across the network, and automatically changing the affected user(s) nickname to an available one. Split mode is usually only applicable to channels, but a split server can also be configured to refuse nickname changes during a split, therefore also reducing the opportunity for collision. These behaviors are not mutually exclusive, and frequently are applied together.

Channel collisions

Channel collisions are more complicated. The default behavior of the original IRC protocol was to always marge the two sides of the channel, but this method was ripe for abuse, because a malicious user could frequently find a server during a netsplit in which a targeted channel did not exist, and by recreating the channel on their side of the split, would have ops on the channel.

Chaos would then ensue when the network healed from the split, as the attacker would usually try to leverage their newfound channel operator privileges to take over the channel by deopping the legitimate channel operators, while the legitimate channel operators would try to fend off the attack by deopping the attacker as quickly as possible. In these days, before any serverside protections against channel collisions existed, this frequently resulted in different parts of the network having inconsistent states, a phenomena known as a desync.

To prevent such abuse, similar strategies were applied as for nickname collisions. The most popular approach was timestamping, under the TS extensions of the IRC protocol, every channel has a numeric timestamp established at the time of its creation. When rejoining two sides of a split network, if the two sides had the same timestamp, the state of the channel would be merged, if the two sides had differing timestamps, the younger incarnation of the channel had its modes forcibly purged, and the older incarnation’s state was forced across the entire network, therefore making network collisions much harder to abuse. IRCNet favored a different approach, using a mechninism called “channel delay”, in which any channel that ceased to exist as a result of a split was barred from being created again for a time. Both methods were not without their flows, but they stopped the most grievous abuses and led to increased stability. However, channel collisions were still a viable means of circumventing bans, keys, and invite-only modes, at least for servers reliant on TS to prevent abuse. A simplified version of channel delay came about to address this, known as split mode, and accompanied by server settings which either disallow joining of channels during a split (NO_JOIN_ON_SPLIT) or disallow channel creation during a split (NO_CREATE_ON_SPLIT). Yet another mechanic has also existed but has fallen out of favor, which was to enforce prohibitive modes against the “losing” side of a split under TS rules, therefore keeping anyone from using a split to get inside of a channel from which they are not welcome.

Notably, the various enhancements to the IRC protocol made to stop abuse of channel collisions did not entirely address desyncs, because users could still initiate mode changes as the network heals from a split, creating the inconsistent state. Most likely, this would happen because someone who should not have been given ops was given them by a legitimate channel op during the split, but it could also happen