He administrado servidores de los tres protocolos. IRC desde 2001. Ejabberd (XMPP) desde 2008. Synapse (Matrix) desde 2019. Cada uno tiene su lugar. Cada uno tiene sus defensores que insisten en que el suyo es el unico viable. Ninguno tiene razon al 100%. Esta es la comparativa que me hubiera gustado leer antes de invertir cientos de horas en cada uno.
Tres protocolos, tres filosofias
IRC (1988): chat en tiempo real, sin persistencia. Lo que no ves cuando pasa, lo pierdes. Protocolo simple, texto plano, eficiente. Diseno de la era de los modems.
XMPP (1999): mensajeria extensible. XML como formato base, extensible via XEPs (XMPP Extension Protocols). Federado desde el diseno. Pensado para reemplazar protocolos propietarios (ICQ, MSN, AIM). Soporta presencia, chat grupal, transferencia de archivos.
Matrix (2014): comunicacion descentralizada con historial persistente. JSON sobre HTTP/HTTPS. Federado con sincronizacion eventual de estado. Piensa de si mismo como \"el sucesor de IRC y XMPP\". Soporta texto, voz, video, bridges a otras plataformas.
IRC: simplicidad radical
IRC es el mas viejo y el mas simple. Su arquitectura es un spanning tree de servidores que reenvian mensajes en tiempo real. No almacena historial por defecto. No tiene cuentas de usuario a nivel de protocolo (NickServ es un hack). No tiene presencia (aparte de AWAY). No tiene multimedia.
Lo que si tiene: eficiencia extrema. Un servidor IRC maneja 10.000 usuarios con 200 MB de RAM. Un cliente corre con 20 MB. El protocolo es texto puro — debugeable con telnet. La latencia es de milisegundos. No hay overhead de serializacion XML o JSON.
IRC es perfecto cuando necesitas: chat grupal en tiempo real, bajo consumo de recursos, integracion facil con herramientas Unix, y anonimato sin registro obligatorio.
XMPP: la promesa federada
XMPP (originalmente Jabber) fue disenado como un protocolo de mensajeria instantanea federado. La idea: cualquiera puede montar un servidor XMPP y sus usuarios pueden comunicarse con usuarios de otros servidores, como email. Tu direccion es usuario@servidor.com — identica conceptualmente a una direccion de correo.
XMPP soporta de forma nativa lo que IRC necesita hacks para lograr: cuentas de usuario, presencia (online, away, busy), mensajes offline, transferencia de archivos, chat grupal (MUC), y cifrado end-to-end (OMEMO). Todo definido en XEPs estandarizados.
El problema de XMPP es la fragmentacion de XEPs. Hay cientos de extensiones y ningun servidor o cliente las implementa todas. El resultado: dos servidores XMPP pueden federarse pero no soportar las mismas features. Llamadas de voz funcionan en un cliente pero no en otro. El cifrado OMEMO funciona entre algunos clientes pero no todos.
# Ejemplo de stanza XMPP (XML):
Hola desde XMPP
# Comparar con IRC:
:marco!user@host PRIVMSG amigo :Hola desde IRC
# La diferencia en overhead es obvia.
# El mensaje XMPP tiene ~200 bytes.
# El mensaje IRC tiene ~50 bytes.XMPP tuvo su momento entre 2005 y 2012. Google Talk usaba XMPP. Facebook Chat usaba XMPP. Luego ambos lo abandonaron por protocolos propietarios. Ese abandono fue un golpe del que XMPP nunca se recupero en adopcion masiva. Hoy, XMPP esta vivo pero en un nicho similar al de IRC: usuarios tecnicos que valoran la federacion y la independencia.
Matrix: el sucesor ambicioso
Matrix se presento como la solucion a los problemas de IRC y XMPP. Federado como XMPP, pero con un modelo de datos diferente: cada sala (room) tiene un historial completo que se sincroniza entre todos los servidores participantes. No importa cuando te unes — puedes leer todo el historial desde el principio.
El modelo de datos es poderoso pero costoso. Cada evento en Matrix (mensaje, cambio de estado, reaccion) es un objeto JSON firmado que se replica a todos los servidores que tienen usuarios en esa sala. El servidor referencia (Synapse, en Python) es notoriamente pesado en recursos.
Matrix resuelve problemas reales: historial persistente, cuentas con identidad verificable, E2EE por defecto (Megolm/Olm), multimedia nativa, bridges a IRC/Slack/Discord/Telegram. El cliente referencia (Element) es una aplicacion web completa con voz y video.
Los problemas: Synapse consume mas recursos que cualquier IRCd o servidor XMPP. Una instancia de Synapse con pocas salas activas puede usar 1-2 GB de RAM y cantidades significativas de disco. La federacion es lenta — unirse a una sala grande puede tardar minutos mientras se sincroniza el historial. Y Element, aunque funcional, no es ligero.
Comparativa tecnica
# Tabla comparativa:
| Aspecto | IRC | XMPP | Matrix |
|----------------------|--------------|--------------|----------------|
| Ano de creacion | 1988 | 1999 | 2014 |
| Formato | Texto plano | XML | JSON/HTTP |
| Federacion | No* | Si | Si |
| Historial persistente| No** | Parcial*** | Si |
| E2EE | No | Si (OMEMO) | Si (Megolm) |
| Multimedia | No | Si | Si |
| Presencia | Basica | Completa | Completa |
| Cuentas nativas | No | Si | Si |
| Bridges | Limitado | Limitado | Extenso |
| RAM servidor (1k usr)| 50-100 MB | 200-500 MB | 1-3 GB |
| RAM cliente | 10-30 MB | 50-200 MB | 200-500 MB |
| Latencia tipica | <50ms | 50-200ms | 100-500ms |
# * IRC no federa entre redes diferentes
# ** Requiere bouncer o chathistory (IRCv3)
# *** Depende de la configuracion del servidor (MAM XEP-0313)Consumo de recursos
El consumo de recursos es donde las diferencias son mas dramaticas y donde la discusion se vuelve menos abstracta:
- IRC: Un IRCd con 1.000 usuarios usa 50-100 MB de RAM. Un Eggdrop bot usa 10 MB. Un cliente (irssi) usa 15 MB. Todo el stack cabe en un VPS de 512 MB.
- XMPP: Ejabberd con 1.000 usuarios usa 200-500 MB (Erlang VM). Prosody (en Lua) es mas ligero: 100-200 MB. Clientes web (Converse.js) usan 100-200 MB. Stack completo: VPS de 1 GB.
- Matrix: Synapse con 1.000 usuarios activos usa 1-3 GB de RAM y cantidades crecientes de disco (la base de datos crece con cada evento). Dendrite (implementacion Go, mas nueva) es mas ligero pero menos maduro. Element Web usa 200-500 MB en el navegador. Stack completo: VPS de 4 GB minimo.
Para un administrador que paga servidores de su bolsillo — como es comun en comunidades IRC — la diferencia entre un VPS de 5 EUR/mes (IRC) y uno de 20-40 EUR/mes (Matrix) es significativa. No es un argumento tecnico — es un argumento economico real.
Cual elegir
Usa IRC si: tu comunidad es tecnica, valoras la simplicidad, tus usuarios ya saben IRC, quieres el menor overhead posible, o integras con herramientas Unix.
Usa XMPP si: necesitas mensajeria 1:1 con presencia y offline messages, tus usuarios valoran E2EE, quieres federacion real, y puedes tolerar la fragmentacion de clientes.
Usa Matrix si: necesitas historial persistente, multimedia, bridges a otras plataformas, E2EE por defecto, y puedes invertir en infraestructura (RAM, disco).
Usa bridges si: tu comunidad esta fragmentada entre plataformas. Un bridge IRC-Matrix permite que los usuarios de IRC sigan en IRC y los de Matrix usen Element, viendo los mismos mensajes. No es perfecto — los bridges tienen latencia y pierden funcionalidades especificas de cada protocolo — pero es mejor que forzar a todo el mundo a migrar.
Preguntas frecuentes
Matrix va a reemplazar a IRC?
Para algunas comunidades, ya lo hizo (Mozilla migro a Matrix en 2020). Para otras, no muestra signos de ocurrir (el kernel Linux, Debian, FreeBSD siguen en IRC). La coexistencia via bridges es el escenario mas probable a medio plazo.
XMPP esta muerto?
No. Conversations (Android), Gajim (desktop), y Dino (desktop) son clientes activamente desarrollados. Ejabberd y Prosody son servidores maduros. La adopcion es menor que la de Matrix, pero la comunidad sigue activa y el protocolo es solido.
Puedo migrar de IRC a Matrix sin perder usuarios?
Con un bridge (como Heisenbridge o matrix-appservice-irc), los usuarios de IRC ven a los de Matrix como usuarios IRC normales y viceversa. No es una migracion — es una convivencia. La experiencia no es identica pero es funcional.