May 2026 • Privacy Infrastructure

IRCv3: What Changed, and Why It Matters

IRCv3 is not a new protocol. It is the same IRC from 1993, extended through a formal capability negotiation system that lets modern clients and servers use new features while remaining wire-compatible with everything that came before.

IRC Is Not Dead. It Evolved.

IRC was designed in 1988 by Jarkko Oikarinen. The core protocol — RFC 1459, formalised in 1993 — defined how clients connect to servers, join channels, and exchange messages. For its time, it was remarkably well-designed: federated, decentralised, text-based, and requiring no account registration with a central authority.

By 2010, IRC had a reputation problem. Compared to Slack and Discord, IRC felt primitive: no message history when you reconnected, no read receipts, no way to know if a message was delivered. The protocol was frozen in 1993 while everything around it moved.

IRCv3 is the working group that changed this — not by replacing IRC, but by extending it through a formal capability negotiation mechanism.

Capability Negotiation: The Foundation

The central innovation of IRCv3 is the CAP command. Before connecting, a client and server negotiate which extensions both support: 

CAP LS 302
CAP REQ :sasl message-tags batch chathistory
CAP ACK :sasl message-tags batch chathistory

A client that does not send CAP LS gets classic IRC behaviour. A client that does gets the extended feature set. The same server handles both transparently. This allowed IRCv3 to ship individual features as stable specifications without requiring a protocol flag day.

SASL: Authentication Done Right

Classic IRC authentication was NICKSERV IDENTIFY password — a plaintext password sent as a PRIVMSG to a bot. If TLS was not configured, the password crossed the network in the clear.

IRCv3 replaces this with SASL (Simple Authentication and Security Layer), a proper authentication framework used across SMTP, IMAP, and LDAP. The IRCv3 SASL extension supports multiple mechanisms:

EXTERNAL authentication via client certificate means authentication requires possession of the private key, with nothing to intercept in transit.

STS: Strict Transport Security for IRC

The sts capability brings to IRC what HSTS brought to HTTPS. On first connection, the server advertises an STS policy: 

:server CAP * LS :sts=duration=2592000,port=6697

A compliant client records this policy and refuses any future plaintext connection to the server. An attacker who intercepts a subsequent connection attempt cannot downgrade it to plaintext. The window of vulnerability is limited to the first connection — identical to the HSTS model the web has used for over a decade.

Message Tags: Structured Metadata

In classic IRC, every message is a flat text line. Metadata — timestamps, reply references, reactions — had to be embedded in the message text using ad-hoc conventions that legacy clients would render as garbage.

IRCv3 message tags prepend structured key-value metadata to any message:

@time=2026-05-18T09:23:41.000Z;+reply=msg-id-123 :nick!user@host PRIVMSG #channel :response

Standard tags defined by IRCv3 include:

CHATHISTORY: Persistent History Without Logging Everything

The absence of message history when reconnecting was the most-cited reason for moving away from IRC. IRCv3's CHATHISTORY command lets clients request message history from the server on demand: 

CHATHISTORY #channel LATEST * 50
CHATHISTORY #channel BEFORE msgid=abc123 50
CHATHISTORY nick AFTER timestamp=2026-05-18T00:00:00Z 100

Critically, this is a pull model. The server stores only what is configured. An operator who values privacy can set short retention windows — 24 hours, or none at all — without breaking the protocol for clients that request history.

This is the opposite of Discord and Slack, where all history is retained indefinitely, indexed, and accessible to the platform operator regardless of user preferences.

MONITOR: Presence Without Polling

Classic IRC had no efficient way to know when a specific user came online. Clients would repeatedly WHOIS a nick, generating significant server load. IRCv3's MONITOR extension lets clients register a watchlist: 

MONITOR + nick1,nick2,nick3

The server sends RPL_MONONLINE or RPL_MONOFFLINE when a monitored nick changes status. No polling. One event per state change.

Multiline Messages

Classic IRC messages are limited to 512 bytes per line. Long messages had to be split by the client, arriving as separate PRIVMSGs with no indication they belong together. IRCv3's multiline extension uses the batch mechanism to send multiple lines as a single logical message: 

BATCH +ref multiline #channel
@batch=ref PRIVMSG #channel :First line
@batch=ref PRIVMSG #channel :Second line, same message
BATCH -ref

Clients that support multiline display the batch as one coherent message. Legacy clients see each line individually — degraded but functional.

Why IRCv3 and Not Something Else

Matrix, Signal, Discord, and Telegram all solve the "IRC feels old" problem. None of them solve it in a way that is compatible with self-hosting, federation without central authority, zero-dependency client implementation, and protocol transparency.

IRCv3 is implementable. A complete client can be written by one person in a few thousand lines of code. The protocol is a published specification, not a reverse-engineered API. Any language that can open a TCP socket and parse lines can speak IRCv3.

The server we run — Ergo — is a single binary with no external database dependency. It handles message history, account registration, and all IRCv3 extensions internally. It runs on a Tor hidden service. Its configuration file is readable without a manual.

Simplicity, auditability, self-hostability, and federation without central registration: these are the properties that matter for a communication infrastructure that should still be running in ten years without depending on anyone else's continued goodwill. IRCv3 has them.

References

Connect to Our IRC Server

Tor onion (recommended):

2xz3ngedsne2ngd3blpgnrqmeitffnzsnjacdjinu63yi5tjcyfitbid.onion

Ports: 6667 plain  /  6696 TLS 1.3

Full connection details and client recommendations →