IRCv3 en 2026: 48 especificaciones, solo 3 obligatorias, 13 aún en borrador y un sitio web con más commits que el repositorio de especificaciones (1.064 frente a 604)

El 11 de octubre de 2026 alguien publicó ircv3.net en Hacker News: la portada pelada, sin noticia, sin nota de versión. Alcanzó 345 puntos y 292 comentarios. Exactamente la misma URL se publicó el 9 de octubre de 2016 y alcanzó 595 puntos y 217 comentarios. Diez años de distancia, la misma página, el mismo público y, más o menos, el mismo volumen de discusión.

O eso cuenta la historia de un protocolo con una capacidad de permanencia poco común, o cuenta la historia de un proceso de estandarización que lleva una década sin terminar visiblemente el mismo trabajo. Lo interesante es que IRCv3 publica suficientes datos legibles por máquina sobre sí mismo como para comprobar cuál de las dos es. Así que lo comprobé.

Descargué el archivo de registro del propio proyecto, sus seis tablas de compatibilidad, el front matter de sus 50 documentos de especificación, el hito de su hoja de ruta y el historial completo de commits de los dos repositorios. Los números no son ambiguos y apuntan en dos direcciones a la vez, que es justo lo que hace que IRCv3 merezca entenderse en lugar de ridiculizarse.

El registro dice 48 especificaciones. El proyecto dice que tres son obligatorias.

IRCv3 no guarda su inventario de especificaciones en prosa. Lo guarda en _data/irc_versions.yml, el archivo sobre el que itera su web para dibujar todas las tablas de compatibilidad. Analizado, contiene 48 especificaciones en una sección llamada Stable, más una segunda sección llamada Proposed Pull Requests que contiene cero especificaciones.

Dentro de esas 48:

Las tres entradas obligatorias son cap-3.1, cap-3.2 y cap-notify. Las tres están definidas en un único documento, capability-negotiation.md. Dicho de otro modo: si se le pregunta qué tiene que implementar un programa para ser «IRCv3», el registro del propio proyecto responde con tres elementos relacionados de un solo archivo y luego 45 opcionales.

Es una decisión de diseño deliberada y el archivo lo dice. Su comentario de cabecera reza: «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». El proyecto dejó de publicar paquetes versionados hace años y el nombre de la sección nunca lo siguió. La consecuencia es que 13 especificaciones marcadas como draft aparecen bajo un encabezado que dice Stable. En el sitio renderizado la distinción sobrevive como una clase CSS (class="draft" frente a class="required"), no como una afirmación que un lector note.

El repositorio de especificaciones cuenta lo mismo con más precisión. De sus 50 documentos markdown, 13 llevan work-in-progress: true en el front matter, uno lleva deprecated: true y 36 son incondicionales. Los 13 archivos WIP y las 13 marcas draft del registro son exactamente las mismas 13 especificaciones: dos estructuras independientes que coinciden, que es la señal más limpia que hay en este conjunto de datos.

La inversión entre repositorios: 604 commits para el protocolo, 1.064 para el sitio web

Aquí está el número que reencuadra toda la discusión.

El repositorio del sitio web tiene 460 commits más que el de especificaciones —una proporción de 1,76×— pese a haberse creado tres años después. Además se actualizó el día anterior al hilo de Hacker News; el de especificaciones lleva 70 días sin tocarse.

Parte de esa diferencia es mecánica: un sitio Jekyll acumula commits de CSS, tipografías, redirecciones y ediciones de contenido que un repositorio de especificaciones no acumula. Pero la dirección es difícil de discutir si se mira el ritmo anual del propio repositorio de especificaciones:

El año punta fue 2015. A partir de ahí la línea cae durante siete años hasta un suelo de 8 commits en 2025, menos de uno cada seis semanas. 2026 sí es un rebote real: 30 commits concentrados en una ráfaga de febrero a mayo (9, 7, 4, 7) que produjo la etiqueta de cliente reply, la especificación de WebSocket y el borrador de oper-tag. Y después, nada desde el 3 de agosto de 2026.

El tercer repositorio, ircv3-ideas, merece una frase: un commit, sin tocar desde 2019, 96 issues abiertos. Para lo que fuera esa cola, dejó de usarse hace siete años y nadie la ha cerrado.

La hoja de ruta es un único hito creado en marzo de 2016

La hoja de ruta de IRCv3 no es un documento. Es el hito #4 de GitHub en el repositorio de especificaciones, titulado «Roadmap»: «This is the rolling technical roadmap for IRCv3».

Y los seis elementos abiertos, con su edad a 12 de octubre de 2026:

La edad mediana de un elemento abierto de la hoja de ruta es de 2.055 días: 5,6 años. La media, 2.075 días. Cinco de los seis son anteriores a 2022; el más antiguo es anterior incluso a la resaca del hilo de Hacker News de 2016.

Esta es la única parte de la crítica popular que se verifica exactamente. Un comentarista que firma como dist-epoch escribió en el hilo de 2026: «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». La distribución real de los seis abiertos es 2017: 1, 2020: 2, 2021: 2, 2025: 1. La afirmación es certera en la forma y ligeramente injusta en un punto: el elemento abierto más nuevo es de abril de 2025 y 2026 produjo cuatro cierres.

Qué miden de verdad las tablas de compatibilidad

Esta es la parte que me sorprendió, porque las tablas son mejor evidencia que la hoja de ruta y rara vez se leen con cuidado.

Las tablas se generan a partir de YAML donde cada programa lleva un mapa support, y cada celda puede estar en uno de cuatro estados: compatible, partial, na o ausente (que se dibuja como «No»). Hay 103 entradas de software repartidas en seis listas —51 filas de clientes, 18 redes, 11 servidores, 11 librerías, 8 puentes, 4 servicios— puntuadas contra 49 claves de especificación estables más 6 mecanismos SASL.

Esta es la cobertura en las 18 redes listadas, ordenada por lo recientemente que se tocó el documento correspondiente:

En agregado: las especificaciones tocadas por última vez antes del 01-01-2022 promedian un 79,0% de cobertura de red sobre 14 claves. Las tocadas desde el 01-01-2022 promedian un 49,8% sobre 26 claves. El centro de gravedad del protocolo es viejo, y su trabajo nuevo aterriza en una o dos implementaciones.

La lista de servidores dice lo mismo con menos filas: cap-3.1 está en 11/11 (100%) y away-notify en 10/11, pero metadata —el reemplazo en curso del comando METADATA de v3.2— está en 1/11, y lo mismo network-icon, read-marker, pre-away y extended-isupport.

La consecuencia visible para el usuario es exactamente la que describió un comentarista firmado como Retr0id: «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». Las tablas ponen números a eso. En las 18 redes, react-client-tag llega a 10 de 18 y reply-client-tag a 13 de 18: en un tercio o la mitad de las redes listadas, una reacción o una respuesta es invisible para la mitad de la sala.

La contraargumentación es más fuerte que la crítica

Salí a auditar un estándar estancado y no dejé de encontrarme con pruebas de que las implementaciones están más sanas que el estándar.

Lo alto de la tabla de clientes no son los veteranos, sino bIRC con 51 entradas compatibles, ObsidianIRC con 42, Mango con 39, Halloy con 38, IRCafe con 36 e IRCCloud con 36 (Limnoria, el bot, está en 35). Mientras tanto mIRC se queda en 32, Irssi en 17, Konversation y KVIrc en 15, Mozilla Thunderbird en 11, y la cola es real: Pidgin en 5, BitchX en 3, IRC for Android en 3. Cuatro de las 51 filas de clientes llevan una insignia de robot que indica «Development assisted using AI» —IRCafe, The Lounge, ObsidianIRC y jWebIRC—, una señal genuinamente nueva en una tabla que nació con el protocolo de la era de 2012.

La lista de servidores está más viva de lo que permite el género «IRC ha muerto»: Ergo (37), UnrealIRCd (35), InspIRCd (32) y Solanum (25) siguen mantenidos activamente, con pushes en octubre de 2026. Los clientes también: WeeChat publicó el 11-10-2026, The Lounge el 11-10-2026, Halloy el 11-10-2026 e Irssi el 23-09-2026.

Y el mejor argumento contra mi propio marco vino del propio hilo. SaberUK escribió: «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». Contra esa referencia, un grupo de trabajo lento no es un modo de fallo: es la razón por la que el trabajo existe. El mismo comentarista añadió que 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». La acusación de círculo cerrado del hilo de 2016 tiene una réplica en 2026, y el archivo del comité técnico —15 personas con nombre y apellidos, la mayoría vinculadas a un cliente o servidor concreto, presidido por jwheare de IRCCloud— es compatible con cualquiera de las dos lecturas.

Dos correctivos más que conviene llevarse:

progval, miembro del comité técnico, respondió directamente a la acusación de fragmentación: «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». Los largos tiempos de ratificación son, en esa versión, el mecanismo funcionando: reply se retuvo hasta que se entendió el riesgo de divergencia. Una respuesta a ese comentario, de mort96, es la réplica justa: «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?».

Y theshrike79, que lleva años construyendo clientes y bots, sostiene que el protocolo es en buena medida irrelevante: «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». Si eso es cierto, medir IRCv3 por su cobertura de especificaciones mide la cosa equivocada; y las victorias prácticas que la gente describió en el hilo (kstrauser corriendo Ergo con Halloy y Goguma y obteniendo historial en el servidor con «no bouncer required», o user3939382 con Ergo detrás de The Lounge: «Works great. Cheap, performant») vinieron todas de implementaciones, no de documentos recién ratificados.

Las tablas de compatibilidad tienen sus propios problemas de calidad de datos

Una auditoría de una auditoría debería reportarlo, así que:

• El recuento de clientes está inflado. Hay 51 filas, pero solo unos 49 nombres distintos. Mango aparece dos veces (Escritorio y Móvil, ambas con 39). IRCCloud aparece dos veces: como cliente web con 36 y como cliente móvil con 31. El mismo producto, dos perfiles de compatibilidad distintos en el mismo archivo. IRCCloud Teams aparece en las listas de servidores y de redes (18 y 22).
• Una de las «organizaciones participantes» está archivada. El sitio nombra a HexChat entre sus organizaciones participantes. hexchat/hexchat está archivado desde el 19-08-2024, con 3.227 estrellas y 6 watchers, y HexChat no tiene ninguna fila en la tabla de clientes. Es, según cómo se cuente, un participante obsoleto o una medición que falta.
• La sección de pipeline del registro está vacía. Proposed Pull Requests no contiene ninguna especificación, así que la única parte del sitio que debería mostrar trabajo en curso no muestra nada.
• Una especificación ratificada que fracasó en producción está documentada, no escondida. El texto del propio sitio dice que el trabajo de metadata-2 sustituye «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». Una de las pocas especificaciones que llegó a 1 de 11 servidores se está reescribiendo porque no se pudo implementar. Es un precedente útil: el fallo lo detectaron los operadores de servidores, no el proceso.
• La cadencia de actualizaciones está documentada como deteriorada. Los posts de resumen del proyecto son 11-2016, 01-2017, 01-2018, 06-2019, 02-2020, 11-2021, 11-2022, 11-2024 y 02-2026: nueve entradas en diez años, con un hueco de 24 meses y luego otro de 15. El de febrero de 2026 abre así: «We missed the November 2025 update, so this is a summary of working group activity since Nov 2024». Y contiene la frase «Despite our own lack of updates, there’s a lot going on in the ecosystem». Siete meses y medio después no hay siguiente entrada.

Qué significa esto si vas a elegir o a construir

Elegir software. Trata las tablas como un mapa de la última década y no como una guía de 2026, y lee columnas concretas en lugar de totales. Un total alto es, en buena parte, una nota por implementar extensiones de 2013. Si lo que quieres es historial sin conexión, mira específicamente las columnas chathistory y read-marker —ahí viven los 3/18 y las implementaciones únicas— y mira también la columna de servidor, porque el historial es una capacidad del lado servidor. La combinación que se repite en el hilo es Ergo (servidor) con Goguma, Halloy, Mango o The Lounge encima, y esa combinación es la que elimina la necesidad de un bouncer.

Construir un cliente. El registro es el documento de alcance honesto, y es más alentador que la hoja de ruta: cap-3.1, cap-3.2 y cap-notify son todo el conjunto obligatorio. Las 13 especificaciones draft están marcadas así por algo (siguen cambiando: react ganó una etiqueta +draft/unreact en febrero de 2026), así que impleméntalas detrás de la negociación de capacidades y cuenta con que el formato cambie. La marca hide-if-no-support del registro indica qué especificaciones solo se muestran cuando alguien las soporta; esas son las que hoy sostiene una única implementación.

Contribuir. El trabajo de especificaciones ocurre como pull requests contra ircv3-specifications, y los elementos abiertos de la hoja de ruta son la declaración del propio proyecto sobre lo que está sin terminar: cinco de seis llevan ahí cinco años o más. El cuello de botella que nombra el hilo no es la capacidad de revisión, sino el tiempo y el dinero de los mantenedores: «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». Eso es un problema de financiación vestido de problema de documentación.

Preguntas frecuentes

¿Está muriendo IRC? No, y para las implementaciones los datos dicen lo contrario. WeeChat, The Lounge, Halloy, UnrealIRCd, InspIRCd, Ergo y Solanum publicaron cambios a los pocos días de esta auditoría. El repositorio que se ha quedado en silencio es el de especificaciones: 8 commits en 2025, 30 en 2026 y 70 días de silencio desde el 3 de agosto de 2026.

¿Cuántas especificaciones tiene IRCv3? El registro lista 48 entradas en su sección Stable, de las cuales 13 están marcadas draft y 1 deprecated. El repositorio de especificaciones contiene 50 documentos markdown. Solo 3 entradas están marcadas como required.

¿Por qué el repositorio de la web está más activo que el de especificaciones? 1.064 commits frente a 604. Parte es mecánico —un sitio Jekyll acumula commits de tipografía, fuentes, redirecciones y contenido—, pero el historial del repositorio de especificaciones cae de un máximo de 123 en 2015 a 8 en 2025, así que la inversión refleja un desplazamiento real de dónde va el trabajo.

¿Necesito un bouncer en 2026? Depende del servidor, no del cliente. Con un servidor que implemente chathistory —Ergo es el que se repite en los comentarios y el que más puntúa en la tabla de servidores, con 37 entradas— obtienes historial sin conexión sin bouncer. Contra un servidor que no lo implemente, sigues necesitando ZNC. chathistory está en 3 de 18 redes listadas y en 2 de 11 servidores.

¿Es fiable la tabla de compatibilidad? Como instantánea de la capacidad declarada es lo mejor que hay, y es la razón por la que esta auditoría ha sido posible. Pero lista 51 filas de clientes para unos 49 clientes, puntúa a IRCCloud con 36 y con 31 en dos categorías distintas, y sigue presentando un proyecto archivado como organización participante. Verifica la columna concreta que te importe.

¿Quién decide qué entra en IRCv3? Un comité técnico de 15 personas, la mayoría vinculadas a un cliente o servidor ya existente, presidido por jwheare de IRCCloud. El proyecto se describe a sí mismo como «a semi-formal group of IRC developers» sin barreras a propuestas externas, lo cual es a la vez una descripción justa y un recordatorio de que la producción de un comité voluntario está limitada por el tiempo libre de sus miembros.

La conclusión que sostienen los números

Más o menos una década después de llegar a portada la primera vez, el problema de IRCv3 no es que nadie lo haya implementado. Las 103 entradas de software, las 51 filas de clientes, el hecho de que cap-3.1 esté al 100% de los clientes y las redes listadas: todo eso es un estándar que venció. El problema es que venció hace tanto que su propio inventario principal es en buena parte arqueología: 48 especificaciones de las que 3 son obligatorias, 13 todavía en borrador bajo un encabezado que dice Stable, un hito de hoja de ruta de 2016 cuyo elemento abierto mediano tiene 5,6 años, y un repositorio cuyo sitio web acumula 460 commits más que sus especificaciones.

La forma más útil de leerlo no es como un escándalo. Es una medición de lo que un grupo de estandarización voluntario puede sostener cuando las implementaciones prosperan, el dinero no está y la alternativa —el IETF— es, según el testimonio de alguien que lo intentó, peor. Los documentos de IRCv3 describen el IRC moderno mejor que cualquier otra cosa; simplemente no todos se escribieron hace poco, y el propio YAML del proyecto es inusualmente honesto al admitirlo.