IRC Server Linking: Spanning Trees, Mesh Dreams, and Reality

Every IRC network is a tree. Not metaphorically — literally. Servers connect to each other in a tree topology with no loops. Remove one link and the tree splits in two. That's a netsplit. This architecture was defined in 1988, and despite decades of complaints about its fragility, nobody has successfully replaced it. There are reasons for that.

The Spanning Tree Model

In a spanning tree, each server connects to one or more other servers, but there is exactly one path between any two servers. No redundant links. No alternative routes. If ServerA connects to ServerB connects to ServerC, and the A-B link dies, A and C cannot communicate. Period.

Typical IRC network topology:

         Hub1
        / | \
    Leaf1 Leaf2  Hub2
                / | \
           Leaf3 Leaf4 Leaf5

If the Hub1-Hub2 link breaks:
  [Hub1-Leaf1-Leaf2] and [Hub2-Leaf3-Leaf4-Leaf5] become isolated.

This seems like a terrible design choice, and in some ways it is. But the spanning tree has one critical advantage for a real-time messaging protocol: message routing is trivial. To send a message from any server to any other server, you just forward it toward the destination along the single possible path. No routing tables, no path computation, no convergence delays. The topology is the routing table.

Compare this with mesh networks, where multiple paths exist between nodes. Mesh routing requires each node to maintain routing tables, handle route changes, and deal with the possibility of messages taking different paths and arriving out of order. For a protocol where message ordering matters (chat messages in a channel should appear in a consistent order), mesh introduces complexity that the spanning tree elegantly avoids.

Link Blocks: Configuring Server Connections

Server-to-server links are configured through link blocks in the ircd configuration file. Here's an example from UnrealIRCd:

link hub.example.net {
    incoming {
        mask *@198.51.100.0/24;
    };
    outgoing {
        bind-ip 198.51.100.5;
        hostname hub.example.net;
        port 6900;
        options { tls; autoconnect; };
    };
    password "shared-secret-here" { spkifp; };
    hub *;
    class servers;
};

Key elements of a link block:

• incoming/outgoing: Defines which direction the connection initiates. Usually both sides configure both directions, but only one side actually connects (the one with autoconnect).
• password: A shared secret for authentication. Modern configurations use SPKI fingerprints (spkifp) or TLS certificate verification instead of plaintext passwords.
• hub: Specifies what this server is allowed to introduce. A hub * means it can introduce any server. A leaf server would have no hub line, meaning it can only introduce itself.

InspIRCd uses a similar but differently formatted configuration:

<link name="hub.example.net"
      ipaddr="198.51.100.1"
      port="6900"
      allowmask="198.51.100.0/24"
      sendpass="secret"
      recvpass="secret"
      ssl="gnutls"
      fingerprint="abc123..."
      hidden="no">

<autoconnect period="60"
             server="hub.example.net">

Hub-Leaf Architecture

Large IRC networks organize their servers into hubs and leaves. Hub servers connect to multiple other servers. Leaf servers connect to exactly one hub. This creates a predictable, manageable topology.

Hubs carry the most traffic — they route messages between all the servers connected to them. They need more bandwidth, more CPU, and more memory than leaf servers. A well-designed network has redundant hubs (multiple hub servers, though only one path between any two servers at a time) and geographically distributed leaves.

The hub designation isn't just a convention — it's enforced in the server configuration. A server configured as a leaf cannot introduce other servers. If a leaf tries to link a third server through itself, the hub will reject it. This prevents accidental topology changes that could create routing problems.

Well-designed hub-leaf topology:

    US-Hub ---- EU-Hub ---- Asia-Hub
    /    \      /    \         \
  US-1  US-2  EU-1  EU-2    Asia-1

Acceptable: 3 hubs, 5 leaves, maximum 2 hops between any two servers.

Bad topology (chain):

  Server1 -- Server2 -- Server3 -- Server4 -- Server5

Technically valid, but a netsplit at Server3 isolates 2 servers on each side,
and messages between Server1 and Server5 traverse 4 hops.

Autoconnect and Link Recovery

When a server link breaks, the network needs to reconnect. The autoconnect feature periodically attempts to re-establish broken links. A typical autoconnect interval is 60-300 seconds.

The autoconnect logic is straightforward: if a configured link isn't currently established, try to connect at the specified interval. When the connection succeeds, both servers perform a burst (state synchronization) and the network is whole again.

During the reconnection, users on isolated segments see other users quit and rejoin. Channel state must be reconciled — both sides may have had different channel operators, different bans, different topics. How this reconciliation works depends on the server software and its timestamp implementation (TS5, TS6, or P10 protocol).

Most modern servers use a "timestamp wins" approach. Each channel and nickname has a creation timestamp. When two network halves rejoin, the older timestamp takes precedence. If someone on Side A created channel #test at 14:00:00 and someone on Side B created the same channel at 14:00:05, Side A's state wins. This isn't perfect — you can lose mode changes made on the "losing" side — but it prevents the chaos of the pre-timestamp era where netsplit reconnects were a free-for-all.

State Synchronization: The Burst

When two servers link, they exchange their complete state. This is called the "burst" or "netburst." The connecting server sends information about every user connected to it and every server behind it: nicknames, user modes, channel memberships, channel modes, bans, topics — everything.

For a large server with thousands of users, the burst can be substantial. A server with 5,000 users, each in an average of 3 channels, generates a burst of roughly 15,000-20,000 protocol messages. At typical IRC message sizes, that's several megabytes of data that must be processed before the link is fully synchronized.

During the burst, the network is in a partially connected state. Messages may not reach all users until synchronization completes. Most server software marks the link as "bursting" and queues certain operations until the burst finishes.

# Simplified burst sequence (TS6 protocol):
PASS secret TS 6 :42X
CAPAB :QS EX CHW IE ...
SERVER leaf.example.net 1 :Leaf Server Description
SVINFO 6 6 0 :1693000000

# User introduction:
:42X UID nick 1 1693000000 +i ~user host.example.net 198.51.100.5 42XAAAAAB :Real Name

# Channel introduction:
:42X SJOIN 1693000000 #channel +nt :@42XAAAAAB +42XAAAAAC 42XAAAAAD

Why Mesh Topology Never Worked

Every few years, someone proposes mesh topology for IRC. The argument is always the same: redundant links would eliminate netsplits. If Hub1 and Hub2 had two connections instead of one, losing one link wouldn't split the network.

The problem is message ordering. In a spanning tree, there is exactly one path between any two points, so messages arrive in the order they were sent. In a mesh, messages could take different paths with different latencies, arriving out of order. For a chat protocol, out-of-order messages are unacceptable — you'd see answers before questions.

Solutions exist (sequence numbers, vector clocks, consensus protocols), but they add latency and complexity. IRC's appeal is its simplicity — a message goes in, gets routed through the tree, comes out the other side. Adding distributed systems complexity to solve netsplits would fundamentally change the protocol's character.

XMPP (Jabber) uses a federated model with direct server-to-server connections rather than a spanning tree. Matrix uses a DAG (directed acyclic graph) for message ordering. Both are more resilient than IRC's spanning tree. Both are also significantly more complex to implement and operate. The tradeoff is real.

Modern Linking: TLS, Passwords, and Fingerprints

Modern server linking uses TLS with certificate verification. Instead of shared passwords (which could be intercepted or leaked), servers verify each other's TLS certificate fingerprints. The fingerprint is configured in the link block, and the connection is rejected if the certificate doesn't match.

# UnrealIRCd: Link with TLS fingerprint verification
link hub.example.net {
    outgoing {
        hostname hub.example.net;
        port 6900;
        options { tls; };
    };
    password "sha256:a1b2c3d4e5f6..." { spkifp; };
    class servers;
};

Some networks add an additional layer: server links over VPN tunnels (WireGuard, IPSec) or Tor hidden services. This hides the server IP addresses from each other and from the network, providing defense against targeted attacks on server infrastructure.

The fundamentals haven't changed since 1988. Servers link in a tree. Messages flow through the tree. The tree sometimes breaks. But the details — encryption, authentication, state synchronization — have improved enormously. A modern IRC server link is a TLS-encrypted, certificate-authenticated, timestamp-protected connection. It's the same architecture, built with better materials.