IRCv3 : les extensions qui modernisent IRC

IRCv3 n'est pas une nouvelle version d'IRC. C'est un ensemble d'extensions retro-compatibles qui ajoutent des fonctionnalites modernes au protocole sans casser la compatibilite avec les clients et serveurs existants. Un client qui ne supporte pas IRCv3 continue de fonctionner normalement. Un client qui le supporte obtient des timestamps, de l'historique, une authentification propre, et bien d'autres choses. C'est la bonne approche : ameliorer sans forcer.

Qu'est-ce qu'IRCv3

IRCv3 est un groupe de travail (IRCv3 Working Group) qui redige des specifications pour les extensions du protocole IRC. Contrairement aux RFCs 1459 et 2812 qui etaient des instantanes du protocole a un moment donne, IRCv3 est un processus continu de standardisation par consensus entre les developpeurs de clients et de serveurs.

Le principe fondamental : les extensions sont opt-in. Un client demande les capacites qu'il supporte. Le serveur repond avec celles qu'il supporte. Les deux se mettent d'accord. Si le client ne demande rien, le serveur se comporte comme un serveur IRC classique.

CAP : negociation de capacites

# La negociation CAP est le mecanisme central d'IRCv3.
# Elle se fait au debut de la connexion, avant NICK/USER.

# Client -> Serveur : quelles capacites as-tu ?
CAP LS 302

# Serveur -> Client : voici ce que je supporte
:serveur CAP * LS :multi-prefix sasl server-time
  message-tags echo-message batch chathistory
  account-notify away-notify

# Client -> Serveur : je veux celles-ci
CAP REQ :sasl server-time message-tags echo-message

# Serveur -> Client : accepte
:serveur CAP * ACK :sasl server-time message-tags echo-message

# Client -> Serveur : negociation terminee
CAP END

# Les capacites non demandees ne sont pas activees.
# Un vieux client qui n'envoie pas CAP LS recoit
# le comportement IRC classique sans extensions.

# La version 302 (CAP LS 302) active les extensions
# de la negociation CAP elle-meme :
# - Valeurs dans les capacites (key=value)
# - CAP NEW/DEL (ajout/retrait de capacites en cours de session)
# - Multiline LS (liste sur plusieurs lignes)

Message tags

Les message tags sont la fondation de la plupart des extensions IRCv3. Ils ajoutent des metadonnees aux messages IRC sans modifier le format de base.

# Format sans tags (RFC 1459) :
:nick!user@host PRIVMSG #canal :Bonjour

# Format avec tags (IRCv3) :
@time=2025-01-05T14:30:00.000Z;msgid=abc123 :nick!user@host PRIVMSG #canal :Bonjour

# Les tags sont entre @ et l'espace qui precede le prefix.
# Chaque tag est key=value, separe par ;

# Tags standards :
# time : timestamp du message (ISO 8601)
# msgid : identifiant unique du message
# account : compte NickServ de l'expediteur
# batch : identifiant de batch (groupe de messages)
# label : ID de correlation requete/reponse
# +reply : reference au msgid d'un message precedent
# +react : reaction a un message (emoji)

# Tags client-only (prefixe +) :
# Transmis entre clients via le serveur
# Le serveur ne les interprete pas
# Utilises pour les reactions, replies, typing, etc.

# Limite de taille :
# Les tags ont leur propre limite (8191 octets)
# separee de la limite du message (512 octets).
# Cela permet d'ajouter beaucoup de metadonnees
# sans reduire l'espace pour le message.

Extensions essentielles

# server-time : timestamps sur chaque message
# Sans : vous ne savez pas quand un message a ete envoye
# Avec : @time=2025-01-05T14:30:00.000Z
# Essentiel pour les bouncers et l'historique

# echo-message : le serveur renvoie vos propres messages
# Sans : votre client affiche le message localement
#   sans confirmation que le serveur l'a recu
# Avec : le serveur renvoie le message avec un msgid
#   et un timestamp, confirmant la reception
# Essentiel pour la coherence multi-client

# account-notify : notification quand un user s'identifie
# :nick!user@host ACCOUNT nick_account
# Permet de savoir qui est identifie sans faire /whois

# away-notify : notification quand un user passe absent
# :nick!user@host AWAY :message d'absence
# :nick!user@host AWAY  (retour)
# Permet d'afficher le statut en temps reel

# multi-prefix : tous les prefixes de canal dans NAMES
# Sans : @nick (seulement le prefixe le plus eleve)
# Avec : @+nick (tous les prefixes : op et voice)

# batch : grouper des messages
# Permet d'envoyer un groupe de messages qui forment
# un ensemble logique (historique, netsplit, etc.)
# :serveur BATCH +id type parametres
# @batch=id :nick PRIVMSG #canal :message 1
# @batch=id :nick PRIVMSG #canal :message 2
# :serveur BATCH -id

# sasl : authentification avant enregistrement
# (voir article dedie sur SASL)

# labeled-response : correlation requete/reponse
# Le client envoie un label, le serveur le renvoie
# dans la reponse. Permet au client de savoir
# quelle reponse correspond a quelle requete.
@label=xyz WHO #canal
@label=xyz :serveur 352 ...
@label=xyz :serveur 315 ... :End of WHO

Chathistory

Chathistory est l'extension qui comble le plus gros manque d'IRC : la persistance des messages.

# chathistory permet de recuperer des messages
# anciens depuis le serveur (ou le bouncer).

# Recuperer les 50 derniers messages d'un canal :
CHATHISTORY LATEST #canal * 50

# Recuperer les messages depuis un timestamp :
CHATHISTORY AFTER #canal timestamp=2025-01-05T10:00:00.000Z 50

# Recuperer les messages avant un timestamp :
CHATHISTORY BEFORE #canal timestamp=2025-01-05T14:00:00.000Z 50

# Recuperer les messages entre deux timestamps :
CHATHISTORY BETWEEN #canal \
  timestamp=2025-01-05T10:00:00.000Z \
  timestamp=2025-01-05T14:00:00.000Z 100

# Le serveur repond avec un batch :
:serveur BATCH +history chathistory #canal
@batch=history;time=... :nick PRIVMSG #canal :message 1
@batch=history;time=... :nick PRIVMSG #canal :message 2
:serveur BATCH -history

# Support :
# Serveurs : Ergo (natif), soju (bouncer)
# Clients : Senpai, Goguma, Halloy, Textual
# irssi et WeeChat ne supportent pas encore
# chathistory nativement (scripts en cours)

# Chathistory change fondamentalement l'experience :
# Vous ouvrez votre client, vous voyez les messages
# que vous avez rates pendant votre absence.
# Plus besoin de bouncer pour ca.

Chathistory est l'extension la plus importante pour l'avenir d'IRC. Elle elimine le besoin d'un bouncer pour la plupart des utilisateurs. Mais son adoption est lente : peu de serveurs et de clients la supportent completement en 2025.

Tableau de support

# Support IRCv3 par serveur (2025) :
#                    CAP  SASL  time  tags  echo  history
# UnrealIRCd 6       oui  oui   oui   oui   oui   non
# InspIRCd 4         oui  oui   oui   oui   oui   non
# Ergo               oui  oui   oui   oui   oui   OUI
# Solanum            oui  oui   oui   oui   oui   non
# ngircd             oui  part  oui   non   non   non

# Support IRCv3 par client (2025) :
#                    CAP  SASL  time  tags  echo  history
# irssi              oui  oui   oui   part  non   non
# WeeChat            oui  oui   oui   oui   oui   non
# HexChat            oui  oui   oui   non   non   non
# Senpai             oui  oui   oui   oui   oui   OUI
# Halloy             oui  oui   oui   oui   oui   OUI
# Textual (macOS)    oui  oui   oui   oui   oui   OUI
# mIRC               oui  oui   part  non   non   non

# Bouncers :
# soju               oui  oui   oui   oui   oui   OUI
# ZNC                oui  oui   oui   part  non   non

# Conclusion : le support est fragmente.
# Les clients modernes (Senpai, Halloy) supportent
# presque tout. Les clients historiques (irssi, mIRC)
# sont en retard. Le choix du client determine
# l'experience IRCv3 que vous aurez.