Aller au contenu
Dialova

Documentation IRC · Débutant

Histoire d’IRC : de 1988 aux extensions IRCv3

IRC naît en 1988 : Jarkko Oikarinen développe Internet Relay Chat à l’université d’Oulu, en Finlande. Le protocole rend possible la discussion en temps réel entre plusieurs utilisateurs et évolue ensuite à travers les réseaux, les logiciels et leurs extensions.

Équipe Dialova · Vérifié le

1988 : un outil de discussion qui se diffuse #

Le récit historique rassemblé par Daniel Stenberg situe les débuts à l’été 1988. IRC se diffuse grâce à des clients et des serveurs capables de communiquer entre eux. Son histoire ne se résume pas à une application : des équipes distinctes développent des logiciels et administrent des réseaux.

1993 et 2000 : documenter le protocole #

La RFC 1459, publiée en mai 1993 par Jarkko Oikarinen et Darren Reed, décrit le protocole IRC. Elle a le statut Experimental. En avril 2000, plusieurs documents abordent l’architecture et les protocoles ; la RFC 2812 traite du protocole client et a le statut Informational.

Ces textes sont des repères, pas la garantie que chaque serveur actuel applique une même version figée. Les implémentations ont évolué, parfois avec des différences de modes, de limites et de réponses. La documentation Modern IRC décrit les pratiques modernes et explicite ces écarts.

Réseaux, services et nouvelles interfaces #

La possibilité de relier des serveurs accompagne le développement de réseaux distincts. Les équipes de réseau organisent leurs règles et leurs services, notamment la gestion des comptes et des salons. NickServ et ChanServ sont des noms courants de services, mais leur présence et leurs commandes ne sont pas universelles.

Les interfaces changent également : terminaux, logiciels graphiques, clients Web et bouncers donnent des façons différentes de retrouver une conversation. Ces choix d’interface ne remplacent pas le protocole et n’uniformisent pas les politiques des réseaux.

IRCv3 : étendre sans tout remplacer #

IRCv3 rassemble des spécifications qui ajoutent des mécanismes négociés : authentification, tags, horodatage serveur et regroupement de messages, entre autres. Le client découvre les capacités du serveur avec CAP. Une extension reste utile seulement si les deux côtés la mettent en œuvre et la négocient.

Il n’existe pas un bouton universel transformant tous les réseaux en une même expérience « IRCv3 ». L’historique, la persistance et les identités dépendent encore des capacités disponibles et des choix de chaque service.

Sources et vérification

Les exemples utilisent des pseudos et domaines fictifs, sauf les points de connexion explicitement documentés. Les extensions et réglages propres à un réseau sont signalés dans le texte.