Matrix vs XMPP vs IRC : comparatif technique

On me demande regulierement : "Matrix va remplacer IRC ?" ou "XMPP est mort ?". La reponse courte : non et non. Les trois protocoles coexistent parce qu'ils servent des besoins differents. IRC est un walkie-talkie. XMPP est un telephone. Matrix est un smartphone. Chaque outil a son usage.

Trois protocoles, trois philosophies

• IRC (1988) : Simplicite et ephemere. Messages texte en temps reel. Pas de stockage, pas de media. Le protocole tient en 65 pages (RFC 1459). Un serveur IRC complet tient dans 20 Mo de RAM.
• XMPP (1999) : Extensibilite par XML. Messages, presence, pub-sub, VoIP, IoT. Le protocole de base est simple mais les extensions (XEPs) couvrent des centaines de cas d'usage. Jabber/XMPP a ete utilise par Google Talk et Facebook Messenger avant qu'ils ne migrent vers des protocoles proprietaires.
• Matrix (2014) : Decentralisation et persistance. Chaque serveur a une copie complete de l'historique des salons qu'il heberge. Le protocole est concu pour la synchronisation distribuee, pas juste le relais de messages.

Architecture

# IRC : Spanning Tree
#
# [Client] --> [Serveur A] --- [Serveur B] <-- [Client]
#
# Les serveurs forment un arbre. Les messages sont
# relayees de branche en branche. Pas de stockage.
# Si le lien entre A et B tombe : netsplit.

# XMPP : Federation Client-Server / Server-Server
#
# [Client] --> [Serveur user@serveurA.com]
#                    |
#              [DNS SRV lookup]
#                    |
#              [Serveur contact@serveurB.com] <-- [Client]
#
# Chaque utilisateur a un JID (user@serveur).
# Les serveurs communiquent entre eux via S2S.
# Les messages peuvent etre stockes (MAM extension).

# Matrix : Replicated Event Graph
#
# [Client] --> [Homeserver A]
#                    |
#              [Federation]
#                    |
#              [Homeserver B] <-- [Client]
#
# Chaque homeserver a une COPIE COMPLETE de l'historique
# de chaque salon ou il a des utilisateurs.
# Les messages sont des "events" dans un DAG
# (directed acyclic graph) replique entre serveurs.
# Pas de netsplit : si un serveur est indisponible,
# les autres continuent et synchronisent plus tard.

# Consequence sur la complexite :
# IRC : O(1) par message (relay simple)
# XMPP : O(1) par message (relay + stockage optionnel)
# Matrix : O(n) par message (replication vers n serveurs)
# C'est pourquoi Matrix est le plus gourmand.

Consommation de ressources

# Serveur pour 1 000 utilisateurs actifs :

# IRC (UnrealIRCd) :
# RAM : 50-100 Mo
# CPU : negligeable
# Disque : <100 Mo (logs uniquement)
# VPS : 1 vCPU, 512 Mo RAM suffit

# XMPP (Prosody) :
# RAM : 100-300 Mo
# CPU : faible
# Disque : 1-5 Go (messages stockes)
# VPS : 1 vCPU, 1 Go RAM

# XMPP (ejabberd) :
# RAM : 500 Mo - 1 Go
# CPU : modere (Erlang VM)
# Disque : 1-5 Go
# VPS : 2 vCPU, 2 Go RAM

# Matrix (Synapse, Python) :
# RAM : 1-4 Go
# CPU : significatif (Python, crypto)
# Disque : 10-50 Go (replication complete)
# VPS : 2-4 vCPU, 4 Go RAM minimum

# Matrix (Dendrite, Go) :
# RAM : 500 Mo - 1 Go
# CPU : modere
# Disque : 10-50 Go
# VPS : 2 vCPU, 2 Go RAM
# (Dendrite est plus leger mais moins mature)

# Matrix (Conduit, Rust) :
# RAM : 100-300 Mo
# CPU : faible
# Disque : 5-20 Go
# VPS : 1 vCPU, 512 Mo RAM
# (Conduit est experimental)

L'ecart de ressources est enorme. Un serveur IRC pour 1 000 utilisateurs tourne sur un Raspberry Pi. Un serveur Matrix Synapse pour 1 000 utilisateurs demande un VPS avec 4 Go de RAM. C'est le prix de la persistance et de la replication distribuee.

Fonctionnalites

# Tableau comparatif :

#                    IRC      XMPP     Matrix
# Persistance        non*     oui(MAM) oui
# E2E encryption     non      oui(OMEMO) oui(Megolm)
# Media (images)     non      oui      oui
# VoIP/Video         non      oui(Jingle) oui
# Reactions          non*     oui(XEP) oui
# Threads            non      non      oui
# Typing indicators  non*     oui      oui
# Read receipts      non      oui      oui
# Federation         oui      oui      oui
# Bridges            partiel  oui      oui
# Bots/API           oui      oui      oui
# Clients terminal   oui      oui      oui(gomuks)

# * : Extensions IRCv3 ajoutent chathistory, +react,
#     +typing en opt-in. Mais le support est fragmente.

# Protocole :
# IRC : texte simple (facile a implementer)
# XMPP : XML (verbeux mais structure)
# Matrix : JSON over HTTP (moderne, REST-like)

Federation

Les trois protocoles supportent la federation (plusieurs serveurs qui forment un reseau), mais de maniere tres differente :

• IRC : Federation en arbre (spanning tree). Tous les serveurs doivent utiliser le meme IRCd et se faire confiance mutuellement. La federation IRC est un reseau ferme — vous ne pouvez pas linker votre serveur a Libera.Chat sans leur accord.
• XMPP : Federation ouverte. N'importe quel serveur XMPP peut communiquer avec n'importe quel autre via DNS SRV. C'est comme l'email : user@serveurA peut ecrire a user@serveurB sans accord prealable. Simple et ouvert.
• Matrix : Federation ouverte mais lourde. Quand un utilisateur de votre serveur rejoint un salon sur un autre serveur, votre serveur recoit une copie complete de l'historique du salon. Plus il y a de serveurs federes dans un salon, plus la replication est couteuse.

La federation Matrix est theoriquement superieure (persistance, pas de netsplit) mais pratiquement problematique. Les grands salons federes (comme #matrix:matrix.org) generent un trafic de synchronisation enorme. C'est pourquoi beaucoup d'organisations utilisent Matrix en mode non-federe (un seul serveur).

Quand utiliser lequel

• IRC : Coordination technique en temps reel. Communautes open source. Equipements ou la legerete et le terminal comptent. Quand vous n'avez pas besoin de persistance ou de media.
• XMPP : Messagerie instantanee classique (1-a-1 et groupes). IoT et notification push. Quand vous voulez un protocole ouvert, federe, et leger avec du stockage de messages.
• Matrix : Quand vous avez besoin de persistance, E2E encryption, media, et bridges vers d'autres plateformes. Alternative a Slack/Discord pour les organisations qui veulent le controle de leurs donnees.