IRCv3 in 2026: 48 Specs, Only 3 Required, 13 Still Drafts — and a Website That Out-Commits the Spec Repo 1,064 to 604

On 2026-10-11, someone posted ircv3.net — the bare homepage, no news, no release note — to Hacker News. It reached 345 points and 292 comments. The exact same URL was posted on 2016-10-09 and reached 595 points and 217 comments. Ten years apart, the same page, the same audience, roughly the same volume of argument.

That is either a story about a protocol with unusual staying power, or a story about a standards process that has been visibly not-finishing the same work for a decade. The interesting thing is that IRCv3 publishes enough machine-readable data about itself to check which one it is. So I checked.

I pulled the project’s own registry file, all six support tables, the front matter of all 50 specification documents, the roadmap milestone, and the full commit history of both repositories. The numbers are not ambiguous, and they cut in two directions at once — which is what makes IRCv3 worth understanding rather than mocking.

The registry says 48 specs. The project says three of them are required.

IRCv3 does not keep its specification inventory in prose. It keeps it in _data/irc_versions.yml, the file its website iterates over to render every support table. Parsed, it contains 48 specification entries in a section named Stable, plus a second section named Proposed Pull Requests that contains zero specs.

Inside those 48:

The three required entries are cap-3.1, cap-3.2 and cap-notify. All three are defined inside a single document, capability-negotiation.md. In other words: interrogated about what a piece of software must implement to be “IRCv3”, the project’s own registry answers with three related items from one file, and then 45 optional ones.

This is a deliberate design decision and the file says so. Its own header comment reads: “the usage of ‘stable’ here is a bit legacy — we used to have IRCv3.1, 3.2, 3.3 tagged release versions of IRC specs. now we have a rolling-release.” The project stopped shipping versioned bundles years ago, and the section name never followed. The consequence is that 13 specs marked draft are listed under a heading that says Stable. On the rendered site the distinction survives as a CSS class (class="draft" versus class="required"), not as a statement a reader would notice.

The spec repository tells the same story more precisely. Of its 50 markdown specification documents, 13 carry work-in-progress: true in their front matter, one carries deprecated: true, and 36 are unconditional. The 13 WIP files and the 13 draft registry flags are the same 13 specifications — two independent structures agreeing, which is the closest thing to a clean signal in this dataset.

The repository inversion: 604 commits for the protocol, 1,064 for the website

Here is the number that reframes the whole discussion.

The website repository has 460 more commits than the specification repository — a 1.76× ratio — despite being created three years later. It was also updated the day before the Hacker News thread; the specs repository has been untouched for 70 days.

Some of that difference is mechanical: a Jekyll site accumulates commits for CSS, fonts, redirects and content edits that a specs repository does not. But the direction is hard to argue with when you look at the yearly rhythm of the specs repository itself:

Peak year was 2015. The line then falls for seven years to a floor of 8 commits in 2025 — fewer than one every six weeks. 2026 is genuinely a rebound: 30 commits, concentrated in a February–May burst (9, 7, 4, 7) that produced the reply client tag, the WebSocket spec and the oper-tag draft. And then nothing since 2026-08-03.

The third repository, ircv3-ideas, is worth one sentence: one commit, last touched in 2019, 96 open issues. Whatever that queue was for, it stopped being used seven years ago and nobody has closed it.

The roadmap is a single milestone created in March 2016

IRCv3’s roadmap is not a document. It is GitHub milestone #4 on the specs repository, titled “Roadmap”, “This is the rolling technical roadmap for IRCv3”.

And the six open items, with their age on 2026-10-12:

Median age of an open roadmap item: 2,055 days — 5.6 years. Mean: 2,075 days. Five of the six predate 2022; the oldest predates the 2016 Hacker News thread’s aftermath.

This is the one part of the popular critique that verifies exactly. A commenter posting as dist-epoch in the 2026 thread wrote: “if you look at the linked roadmap, most issues are from 2020/2021, with one from 2017, when Discord appeared. So yeah, we are going to have the Dyson swarm before this is done.” The actual distribution of the six open items is 2017: 1, 2020: 2, 2021: 2, 2025: 1. The claim is accurate in shape, and slightly unfair in one respect — the newest open item is from April 2025, and 2026 produced four closures.

What the support tables actually measure

This is the part that surprised me, because the tables are better evidence than the roadmap and they are rarely read carefully.

The support tables are generated from YAML where each software entry carries a support map, and each cell can be one of four states: supported, partial, na, or absent (rendered as “No”). There are 103 software entries across six lists — 51 client rows, 18 networks, 11 servers, 11 libraries, 8 bridges, 4 services — scored against 49 stable spec keys plus 6 SASL mechanisms.

Here is coverage on the 18 listed networks, sorted by how recently the corresponding spec document was touched:

Aggregated: specs last touched before 2022-01-01 average 79.0% network coverage across 14 keys. Specs last touched since 2022-01-01 average 49.8% across 26 keys. The protocol’s centre of mass is old, and its new work lands on one or two implementations.

The servers list makes the same point with fewer rows: cap-3.1 is 11/11 (100%), away-notify 10/11, but metadata — the WIP replacement for the v3.2 METADATA command — is 1/11, and so are network-icon, read-marker, pre-away and extended-isupport.

The user-facing consequence is exactly what a commenter called Retr0id described: “there are a million optional extensions… This can get especially confusing when people on different clients have divergent views of the same conversation. e.g. some can see the emoji reacts, others can’t. some can see ‘replies’, others can’t.” The tables put numbers on that. On the 18 networks, react-client-tag reaches 10 of 18 and reply-client-tag 13 of 18 — so on a third to a half of listed networks, a reaction or a reply is simply invisible to half the room.

The counter-case is stronger than the critique

I set out to audit a stalled standard and kept running into evidence that the implementations are healthier than the standard.

The top of the client table is not the incumbents. It is bIRC at 51 supported entries, ObsidianIRC at 42, Mango at 39, Halloy at 38, IRCafe at 36, IRCCloud at 36 (Limnoria, the bot, is at 35). Meanwhile mIRC sits at 32, Irssi at 17, Konversation and KVIrc at 15, Mozilla Thunderbird at 11, and the tail is real: Pidgin at 5, BitchX at 3, IRC for Android at 3. Four of the 51 client rows carry a robot badge indicating “Development assisted using AI” — IRCafe, The Lounge, ObsidianIRC and jWebIRC — which is a genuinely new signal in a table that dates to the 2012-era protocol.

The servers list is healthier than the “IRC is dead” genre allows: Ergo (37), UnrealIRCd (35), InspIRCd (32) and Solanum (25) are all actively maintained, with pushes in October 2026. So are the clients: WeeChat pushed 2026-10-11, The Lounge 2026-10-11, Halloy 2026-10-11, Irssi 2026-09-23.

And the strongest argument against my own framing came from the thread itself. SaberUK wrote: “IRCv3 are the consensus-based standards body for modern IRC and has ratified the WebSocket spec. Its very unlikely there will be another IRC RFC because getting anything through the IETF is a bureaucratic nightmare. I was a reviewer for the draft IRC-CTCP RFC and it eventually died because the IETF wanted external reviewers who didn’t work on the spec and that just didn’t exist.” Against that benchmark, a slow working group is not a failure mode — it is the reason the work exists at all. The same commenter added that IRCv3 “isn’t a corporate body, its a semi-formal group of IRC developers. There’s nothing prohibiting you from proposing protocol extensions if they are within the scope of the working group.” The 2016 thread’s accusation of a closed circle has a 2026 rebuttal, and the project’s technical committee file — 15 named people, most affiliated with specific client or server projects, chaired by IRCCloud’s jwheare — is consistent with either reading.

Two more correctives worth carrying:

progval, a technical committee member, answered the fragmentation charge directly: “Emojis and reacts are the only extensions that can cause people to have a meaningfully different view. It’s part of why it took so long to ratify replies, and reacts still are not ratified. We’re also discussing ways for servers to provide a fallback to clients which don’t support them.” The long ratification times are, in that account, the mechanism working — reply was held back until the divergence risk was understood. A reply to that comment, from mort96, is the fair counterpoint: “Uh. I feel like this should be something that’s done before it’s ratified. What if you find out that there is no satisfactory way?”

And theshrike79, who has built clients and bots for years, argues the protocol is largely beside the point: “most of the jank of IRC is client-side and can be fixed on the clients, IRCv3 protocol changes are nice, but not essential for a good experience.” If that is right, then measuring IRCv3 by its spec coverage measures the wrong thing — and the practical wins people described in the thread (kstrauser running Ergo with Halloy and Goguma and getting server-side history with “no bouncer required”, or user3939382 running Ergo behind The Lounge: “Works great. Cheap, performant”) all came from implementations, not from newly ratified documents.

The support tables have their own data-quality problems

An audit of an audit should report this, so:

• The client count is inflated. There are 51 rows but only about 49 distinct names. Mango appears twice (Desktop and Mobile, both at 39). IRCCloud appears twice — as a Web client at 36 and as a Mobile client at 31. Same product, two different support profiles in the same file. IRCCloud Teams appears in both the servers and networks lists (18 and 22).
• One listed “participating organisation” is archived. The site names HexChat among its participating organisations. hexchat/hexchat has been archived since 2024-08-19, with 3,227 stars and 6 watchers — and HexChat has no row at all in the client support table. It is, depending on how you count, either a stale participant or a missing measurement.
• The registry’s pipeline section is empty. Proposed Pull Requests contains zero specs, so the one part of the site that should show work-in-flight shows nothing.
• A ratified spec that failed in production is documented, not hidden. The site’s own text says the metadata-2 work replaces “the v3.2 METADATA command, which was found to have issues related to rate-limiting and excessive notifications, which made it impossible for servers in widespread use to implement.” One of the few specs that reached 1 out of 11 servers is being rewritten because it could not be implemented. That is a useful precedent: the failure was caught by server operators, not by the process.
• The update cadence is documented as slipping. The project’s round-up posts run 2016-11, 2017-01, 2018-01, 2019-06, 2020-02, 2021-11, 2022-11, 2024-11, 2026-02 — nine posts in ten years, with a 24-month gap and then a 15-month gap. The February 2026 post opens: “We missed the November 2025 update, so this is a summary of working group activity since Nov 2024.” It also contains the sentence “Despite our own lack of updates, there’s a lot going on in the ecosystem.” Seven and a half months later there is no next post.

What this means if you are choosing or building

Picking software. Treat the support tables as a map of the last decade rather than a guide to 2026, and read individual spec columns rather than totals. A high total is largely a score for implementing 2013-era extensions. If what you actually want is offline history, check the chathistory and read-marker columns specifically — that is where the 3/18 and single-implementation numbers live — and check the server column too, because history is a server-side capability. The pairing that recurs in the thread is Ergo (server) with Goguma, Halloy, Mango or The Lounge on top, and that pairing is the one that removes the bouncer requirement.

Building a client. The registry is the honest scope document, and it is more encouraging than the roadmap: cap-3.1, cap-3.2 and cap-notify are the whole mandatory set. The 13 draft specs are marked draft for a reason (they still change — react gained a +draft/unreact tag in February 2026), so implement them behind capability negotiation and expect the wire format to move. hide-if-no-support in the registry tells you which specs the site itself only displays when someone supports them; those are the ones where a single implementation is currently carrying the feature.

Contributing. The specs work happens as pull requests against ircv3-specifications, and the open roadmap items are the project’s own statement of what is unfinished — five of six have sat there five years or more. The bottleneck named in the thread is not review bandwidth but maintainer time and money: “People want IRC to have features but are unwilling to support IRC developers to actually implement them and as a result pretty much every single IRC developer (myself included) who isn’t churning out slop is burned out because its a thankless job.” That is a funding problem wearing a documentation problem’s clothes.

FAQ

Is IRC dying? No, and the data says the opposite for implementations. WeeChat, The Lounge, Halloy, UnrealIRCd, InspIRCd, Ergo and Solanum all shipped changes within days of this audit. The repository that has gone quiet is the specification repository — 8 commits in 2025, 30 in 2026, and 70 days of silence after 2026-08-03.

How many specs does IRCv3 have? The registry lists 48 entries in its Stable section, of which 13 are flagged draft and 1 deprecated. The spec repository contains 50 markdown documents. Only 3 entries are flagged required.

Why is the website repository more active than the specs repository? 1,064 commits versus 604. Part of it is mechanical — a Jekyll site accumulates typography, font, redirect and content commits — but the specs repository’s own commit history falls from a 2015 peak of 123 to 8 in 2025, so the inversion reflects a real shift in where the work goes.

Do I need a bouncer in 2026? It depends on the server, not the client. With a server implementing chathistory — Ergo is the one repeatedly named by users and it is the top-scoring server in the support table at 37 entries — you get offline history without a bouncer. Against a server that does not, you still need ZNC. chathistory is at 3 of 18 listed networks and 2 of 11 servers.

Is the support matrix reliable? As a snapshot of claimed capability it is the best thing available, and it is the reason this audit was possible at all. But it lists 51 client rows for roughly 49 clients, scores IRCCloud at 36 and 31 in two different categories, and still claims an archived project as a participating organisation. Cross-check the specific column you care about.

Who decides what goes into IRCv3? A technical committee of 15 people, most affiliated with an existing client or server project, chaired by IRCCloud’s jwheare. The project describes itself as “a semi-formal group of IRC developers” with no bar on outside proposals, which is both a fair description and a reminder that a volunteer committee’s output is bounded by its members’ spare time.

The conclusion the numbers support

Roughly a decade after it reached the front page the first time, IRCv3’s problem is not that nobody implemented it. The 103 software entries, the 51 client rows, the fact that cap-3.1 is at 100% of listed clients and networks — all of that is a standard that won. The problem is that the standard won so long ago that its own headline inventory is mostly archaeology: 48 specs of which 3 are required, 13 still drafts under a heading that says Stable, a roadmap milestone from 2016 whose median open item is 5.6 years old, and a repository whose website has 460 more commits than its specifications.

The most useful way to read that is not as a scandal. It is a measurement of what a volunteer standards group can sustain when the implementations are thriving, the money is absent, and the alternative — the IETF — is, on the testimony of someone who tried it, worse. IRCv3’s documents describe modern IRC better than anything else does; they just were not all written recently, and the project’s own YAML is unusually honest about admitting it.