IRCv3: las extensiones que modernizan IRC

November 05, 2024 — por Marco Pellegrini

IRC no se actualizo formalmente entre el RFC 2812 (2000) y la creacion del IRCv3 Working Group en 2012. Doce anos donde cada IRCd anadio extensiones propietarias incompatibles, cada cliente implemento su propia version de features comunes, y el protocolo se fragmento en dialectos mutuamente inteligibles pero no interoperables. IRCv3 fue el intento de poner orden en ese caos. Esta funcionando.

Que es IRCv3

IRCv3 es un grupo de trabajo que define extensiones estandarizadas para el protocolo IRC. No reemplaza el RFC 1459 — lo extiende. Cada extension es una capability (capacidad) que el cliente solicita y el servidor concede o rechaza. Si el servidor no soporta una extension, el cliente funciona sin ella. Si el cliente no conoce una extension, la ignora.

Este modelo de extensiones incrementales es lo que permite que IRC evolucione sin romper compatibilidad. Un cliente de 2005 puede conectar a un servidor con todas las extensiones IRCv3 habilitadas — simplemente no negocia ninguna y funciona como siempre. Un cliente moderno negocia las extensiones disponibles y obtiene una experiencia mejorada.

Las extensiones se clasifican en tres estados: draft (en desarrollo), proposed (propuesta para adopcion), y ratified (adoptada como estandar). Los clientes y servidores solo deberian implementar extensiones ratified para produccion.

CAP: el mecanismo de negociacion

CAP (Capability Negotiation) es la base de IRCv3. Permite al cliente y al servidor negociar que extensiones usar antes de completar la conexion.

# Secuencia de negociacion CAP:

# 1. Cliente pide la lista de capabilities:
CAP LS 302

# 2. Servidor responde con las disponibles:
:irc.server CAP * LS :multi-prefix sasl server-time \
  message-tags echo-message batch labeled-response \
  account-notify away-notify chghost cap-notify \
  invite-notify setname

# 3. Cliente solicita las que quiere:
CAP REQ :sasl server-time message-tags echo-message batch

# 4. Servidor confirma:
:irc.server CAP * ACK :sasl server-time message-tags echo-message batch

# 5. (SASL authentication si fue solicitada)
# 6. Cliente finaliza negociacion:
CAP END

# 7. Registro normal:
NICK marco
USER marco 0 * :Marco Pellegrini

La version 302 de CAP es la actual. Soporta negociacion de capabilities con valores (sasl=PLAIN,EXTERNAL), listado paginado para servidores con muchas capabilities, y notificacion de cambios (cap-notify).

SASL: autenticacion durante la conexion

SASL fue una de las primeras extensiones IRCv3 y probablemente la mas importante. Permite al usuario autenticarse con NickServ durante el proceso de conexion, antes de que su presencia sea visible en la red.

Los mecanismos SASL soportados:

PLAIN: Usuario y contrasena en base64. Requiere TLS para seguridad.
EXTERNAL: Autenticacion por certificado TLS de cliente (CertFP). El mas seguro.
SCRAM-SHA-256: Autenticacion con desafio-respuesta. La contrasena nunca viaja, ni siquiera en base64. El mas robusto teoricamente, pero con soporte limitado en clientes.

En la practica, SASL PLAIN sobre TLS es lo que la mayoria usa. SASL EXTERNAL (CertFP) es lo que deberian usar. SCRAM-SHA-256 es el futuro pero aun no tiene adopcion suficiente.

Message tags: metadatos en mensajes

Los message tags son la extension que mas impacto ha tenido en la funcionalidad de IRC. Permiten anadir metadatos a cualquier mensaje IRC sin modificar el formato base.

# Formato con tags:
@tag1=valor1;tag2;tag3=valor3 :nick!user@host PRIVMSG #canal :Hola

# Tags estandarizados:

# server-time: timestamp del mensaje
@time=2025-01-15T14:30:00.000Z :nick!user@host PRIVMSG #canal :Hola
# El cliente muestra la hora correcta incluso si el mensaje
# llega tarde (via bouncer, chathistory, etc.)

# msgid: identificador unico del mensaje
@msgid=abc123 :nick!user@host PRIVMSG #canal :Hola
# Permite referenciar mensajes especificos (para replies, reactions)

# account: cuenta NickServ del emisor
@account=marco :nick!user@host PRIVMSG #canal :Hola
# El cliente puede mostrar la cuenta asociada al nick

# +reply: respuesta a un mensaje especifico
@+reply=abc123 :otro!user@host PRIVMSG #canal :De acuerdo
# Permite threading basico en IRC

# +react: reaccion a un mensaje
@+react=abc123 :otro!user@host TAGMSG #canal
# Equivalente a reactions de Slack/Discord, pero en texto

Los message tags resuelven uno de los problemas historicos de IRC: la ausencia de metadatos. Sin server-time, un mensaje reenviado por un bouncer no tiene timestamp confiable. Sin msgid, no hay forma de referenciar un mensaje especifico. Sin account, no sabes si el usuario esta identificado.

Consejo: Los tags con prefijo + (como +reply, +react) son tags de cliente — los envia un cliente y el servidor los reenvia sin procesarlos. Los tags sin prefijo son del servidor. Esta distincion es importante para entender que datos son confiables (del servidor) y cuales no (del cliente).

Chathistory: mensajes perdidos

La extension chathistory resuelve el problema mas fundamental de IRC: los mensajes que pierdes cuando no estas conectado. Permite al cliente solicitar al servidor los mensajes que ocurrieron en un canal o conversacion durante un periodo de tiempo.

# Solicitar historial de un canal:
CHATHISTORY #canal * timestamp=2025-01-15T10:00:00.000Z 100
# Dame los ultimos 100 mensajes de #canal desde esa fecha

# Solicitar mensajes desde el ultimo leido:
CHATHISTORY #canal * msgid=ultimo-msgid-leido 100
# Dame los mensajes que vinieron despues del ultimo que vi

# El servidor responde con un batch de mensajes:
@time=2025-01-15T10:05:00Z :nick1!user@host PRIVMSG #canal :Primer mensaje
@time=2025-01-15T10:06:00Z :nick2!user@host PRIVMSG #canal :Segundo mensaje
...

Chathistory es la extension que mas acerca IRC a la experiencia de Slack o Discord. Ya no necesitas un bouncer solo para no perder mensajes. Si el servidor soporta chathistory, reconectas y pides lo que te perdiste.

El soporte de chathistory varia:

Ergo: Soporte nativo completo. Es el IRCd que mejor implementa chathistory porque fue disenado con el en mente.
Soju (bouncer): Soporte completo. Soju actua como bouncer y almacena historial, exponiendolo via chathistory al cliente.
UnrealIRCd / InspIRCd: No soportan chathistory nativamente. Necesitas un bouncer o un modulo externo.

Otras extensiones utiles

echo-message: El servidor devuelve al cliente sus propios mensajes. Esto confirma que el mensaje fue enviado y permite al cliente mostrarlo con el timestamp correcto del servidor.
batch: Agrupa multiples mensajes relacionados (netsplit, chathistory, etc.) en un solo bloque. El cliente puede procesar el batch completo en vez de mostrar mensajes uno a uno.
labeled-response: Asocia una respuesta del servidor a un comando especifico del cliente. Resuelve la ambiguedad de \"esta respuesta es a mi comando o al de otro?\"
account-notify: El servidor notifica cuando un usuario se identifica o desidentifica. El cliente puede actualizar la interfaz sin hacer WHOIS.
away-notify: El servidor notifica cuando un usuario se pone o quita /AWAY. Sin esto, solo lo descubres al hacer WHOIS.
chghost: El servidor notifica cuando el host de un usuario cambia (ej: despues de identificarse y aplicar cloaking). Sin esto, el cliente muestra el host viejo.
setname: Permite cambiar el realname (GECOS) sin reconectar.
multi-prefix: El servidor muestra todos los modos de un usuario en un canal (@+ para op+voice), no solo el mas alto.

# Ejemplo de batch (netsplit):
@msgid=1 BATCH +netsplit netsplit servidor1 servidor2
@batch=netsplit :nick1!user@host QUIT :servidor1 servidor2
@batch=netsplit :nick2!user@host QUIT :servidor1 servidor2
@batch=netsplit :nick3!user@host QUIT :servidor1 servidor2
BATCH -netsplit

# El cliente puede colapsar todo el batch en un solo mensaje:
# "3 usuarios se desconectaron (netsplit: servidor1 <-> servidor2)"
# En vez de mostrar 3 lineas de QUIT individuales.

Soporte en IRCds y clientes

Estado del soporte IRCv3 en 2025:

Ergo: Soporte excelente. Implementa casi todas las extensiones ratified incluyendo chathistory. Es el IRCd de referencia para IRCv3.
InspIRCd 4: Buen soporte. SASL, server-time, message-tags, echo-message, batch. No chathistory nativo.
UnrealIRCd 6: Buen soporte. Similar a InspIRCd. SASL, server-time, message-tags.
WeeChat: Soporte excelente. Negocia todas las capabilities disponibles automaticamente.
irssi: Soporte basico. SASL, server-time. Algunas extensions requieren plugins.
HexChat: Soporte moderado. SASL, server-time. Desarrollo lento.
Senpai: Soporte excelente. Cliente terminal moderno disenado especificamente para IRCv3.
Halloy: Soporte excelente. Cliente grafico moderno en Rust con IRCv3 completo.

Atencion: No asumas que tu IRCd o cliente soporta una extension especifica. Verifica la documentacion. Las extensions draft pueden cambiar o ser eliminadas. Solo basa tu infraestructura en extensions ratified.

Preguntas frecuentes

IRCv3 rompe compatibilidad con IRC viejo?

No. Las extensiones son opt-in via CAP. Un cliente viejo que no negocia CAP funciona exactamente igual que antes. Un servidor sin extensiones IRCv3 funciona con clientes modernos — simplemente no ofrece las capabilities extra.

IRCv3 convierte IRC en Slack/Discord?

No. IRCv3 anade funcionalidades que hacen IRC mas usable (timestamps, historial, autenticacion), pero no cambia la naturaleza fundamental del protocolo: texto, canales, abierto, federado. IRC sigue siendo IRC.

Debo actualizar mi IRCd para IRCv3?

Si tu IRCd actual no soporta al menos SASL y server-time, si. Estas extensiones son basicas y esperadas por los clientes modernos. UnrealIRCd 6 e InspIRCd 4 las soportan. Si estas en versiones mas viejas, actualiza.