Atheme vs Anope: comparativa de servicios IRC en 2024

April 22, 2024 — por Marco Pellegrini

He instalado, configurado, roto y reparado tanto Atheme como Anope más veces de las que me gustaría admitir. Desde 2003 he operado redes IRC que iban desde 50 usuarios hasta picos de varios miles, y los servicios son el componente que más dolores de cabeza te da cuando falla y que más ignoras cuando funciona bien.

La pregunta "¿Atheme o Anope?" aparece en casi todo foro de operadores IRC. La respuesta corta es que ambos funcionan. La respuesta larga — que es este artículo — es que tienen filosofías de diseño diferentes y la elección depende de qué priorizas.

Contexto: qué son los servicios IRC

Para quien llega nuevo: los servicios IRC son pseudoclientes que se conectan a tu red y proporcionan funcionalidades que el protocolo IRC base no tiene. El protocolo IRC no tiene concepto de "cuentas de usuario" — tu nick es efímero, cualquiera puede usarlo. Los servicios solucionan esto.

Los servicios estándar son:

NickServ — Registro y protección de nicks. Autenticación de usuarios.
ChanServ — Registro y gestión de canales. Permisos, modos, protección.
MemoServ — Mensajes offline entre usuarios registrados.
OperServ — Herramientas administrativas para IRCops.
BotServ — Bots de canal personalizables (solo Anope).
HostServ — Asignación de virtual hosts personalizados.

Antes de Atheme y Anope existían Epona, Magick, IRCS... la mayoría están muertos o abandonados. Hoy, la elección práctica se reduce a estos dos.

Atheme: filosofía y arquitectura

Atheme nació como un rewrite limpio orientado a redes grandes. Su filosofía es minimalismo funcional: hace lo que necesitas, no incluye extras innecesarios, y la configuración es explícita.

Puntos fuertes de Atheme

Modelo de cuentas unificado — Atheme usa "accounts" en vez de "nicks registrados". Un usuario tiene UNA cuenta y puede asociar múltiples nicks a ella. Esto es conceptualmente más limpio que el modelo de Anope.
SASL nativo integrado — Atheme fue el primero en implementar SASL como parte del core. La integración es profunda y sólida.
Código limpio — El codebase es C99, bien estructurado, con documentación interna decente. Contribuir es viable.
Bajo consumo de recursos — En mi red con ~8.000 cuentas registradas, Atheme usaba ~45 MB de RAM. En la misma red, Anope usaba ~70 MB.

Configuración básica de Atheme

# atheme.conf - Extracto relevante

serverinfo {
    name = "services.irc6.net";
    desc = "IRC6 Network Services";
    recontime = 10;
    netname = "IRC6";
    hidehostsuffix = "irc6.net";
    adminname = "Marco Pellegrini";
    adminemail = "admin@irc6.net";
    auth = none;  # SASL se gestiona por módulo
};

uplink {
    name = "hub.irc6.net";
    host = "127.0.0.1";
    port = 7000;
    send_password = "link_password_aqui";
    receive_password = "link_password_aqui";
    protocol = "unreal4";
};

# Módulos NickServ
loadmodule "modules/nickserv/main";
loadmodule "modules/nickserv/identify";
loadmodule "modules/nickserv/register";
loadmodule "modules/nickserv/set";
loadmodule "modules/nickserv/cert";
loadmodule "modules/nickserv/enforce";

# Módulos ChanServ
loadmodule "modules/chanserv/main";
loadmodule "modules/chanserv/register";
loadmodule "modules/chanserv/flags";
loadmodule "modules/chanserv/op";
loadmodule "modules/chanserv/voice";
loadmodule "modules/chanserv/kick";
loadmodule "modules/chanserv/ban";
loadmodule "modules/chanserv/topic";
loadmodule "modules/chanserv/invite";

# SASL
loadmodule "modules/saslserv/main";
loadmodule "modules/saslserv/plain";
loadmodule "modules/saslserv/external";

Puntos débiles de Atheme

Desarrollo estancado — El repositorio oficial ha tenido periodos largos sin actividad. Hay forks activos (atheme-services), pero la situación no es ideal.
Documentación dispersa — La wiki oficial tiene huecos. A veces tienes que leer el código fuente para entender una opción.
Sin BotServ — Si quieres bots de canal integrados en los servicios, Atheme no lo ofrece.

Anope: la alternativa popular

Anope es el sucesor de Epona (que era sucesor de Services for IRC Networks). Tiene una historia larga y una comunidad de usuarios más amplia que Atheme. Su filosofía es inclusiva: viene con todo incluido y tú desactivas lo que no necesitas.

Puntos fuertes de Anope

BotServ — Bots de canal configurables que reemplazan al pseudocliente ChanServ en canales individuales. Los usuarios pueden personalizar el nick y el comportamiento del bot en su canal.
Módulos extra — HostServ completo, fantasías en canales, y módulos de terceros abundantes.
Documentación mejor — La wiki de Anope es más completa y mantenida que la de Atheme.
SQL nativo — Anope puede usar MySQL/MariaDB, PostgreSQL o SQLite como backend. Atheme usa su formato propio (flatfile o OpenSEX) con módulo SQL opcional.
Desarrollo más activo — Releases más frecuentes y comunidad de desarrollo más grande.

Configuración básica de Anope

# anope.conf - Extracto

define {
    name = "services.host"
    value = "services.irc6.net"
}

uplink {
    host = "127.0.0.1"
    port = 7000
    password = "link_password_aqui"
}

serverinfo {
    name = "services.irc6.net"
    description = "IRC6 Network Services"
    id = "00A"
    pid = "data/anope.pid"
    motd = "conf/services.motd"
}

module {
    name = "unreal4"
}

networkinfo {
    networkname = "IRC6"
    nicklen = 31
    userlen = 10
    hostlen = 64
    chanlen = 32
}

# NickServ
module { name = "nickserv" }
nickserv {
    nick = "NickServ"
    defaults = "kill_quick ns_secure ns_private hide_email"
    expire = 90d
    enforceruser = "enforcer"
    enforcerhost = "services.irc6.net"
    releasetimeout = 1m
    maxaliases = 5
}

# ChanServ  
module { name = "chanserv" }
chanserv {
    nick = "ChanServ"
    defaults = "keeptopic peace cs_secure"
    expire = 120d
    maxregistered = 20
}

# BotServ
module { name = "botserv" }
botserv {
    nick = "BotServ"
    defaults = "greet fantasy"
}

# Base de datos SQL
module { name = "db_sql" }
db_sql {
    engine = "mysql/main"
}
mysql {
    name = "mysql/main"
    database = "anope"
    server = "127.0.0.1"
    username = "anope"
    password = "password_sql"
    port = 3306
}

Advertencia: Si usas Anope con MySQL y tu base de datos crece mucho (más de 50.000 cuentas), monitoriza el rendimiento de las queries. He visto instancias donde las consultas de expiración de nicks tardaban minutos y bloqueaban el servicio. Añade índices apropiados y ejecuta OPTIMIZE TABLE periódicamente.

NickServ: registro y gestión de nicks

La diferencia fundamental está en el modelo de datos.

Atheme: Registras una CUENTA. Tu nick principal es el nombre de la cuenta. Puedes agrupar nicks adicionales con /ns GROUP. Todo se ancla en la cuenta.

Anope: Registras un NICK. Puedes agrupar nicks adicionales. El primer nick registrado es el "display" por defecto, pero conceptualmente son nicks agrupados, no una cuenta con aliases.

# Atheme - Registro
/msg NickServ REGISTER password email@ejemplo.com
/msg NickServ GROUP nick_secundario
# Resultado: cuenta "marco" con nicks [marco, marco_, marco__]

# Anope - Registro (mismo flujo para el usuario, diferente internamente)
/msg NickServ REGISTER password email@ejemplo.com
/msg NickServ GROUP nick_secundario password
# Resultado: nick "marco" como core con aliases [marco_, marco__]

La diferencia parece sutil, pero afecta cómo funcionan los permisos en ChanServ, cómo se muestran los datos en /ns INFO, y cómo se gestionan los metadatos.

ChanServ: gestión de canales

Aquí es donde las diferencias se hacen más visibles:

Atheme usa FLAGS:

# Atheme - Sistema de flags granular
/msg ChanServ FLAGS #canal usuario +vVoOtsirf
# v = voice, V = autovoice, o = op, O = autoop
# t = topic, s = set, i = invite, r = recover, f = flags

# Ver flags actuales
/msg ChanServ FLAGS #canal
# +votsri  marco
# +vV      usuario_regular

# Templates predefinidos
/msg ChanServ FLAGS #canal usuario +VOP  (equivale a vVoOtsirf)

Anope usa ACCESS con niveles numéricos (y opcionalmente XOP):

# Anope - Sistema XOP (simplificado)
/msg ChanServ VOP #canal ADD usuario     # Voice
/msg ChanServ HOP #canal ADD usuario     # Halfop
/msg ChanServ AOP #canal ADD usuario     # Op
/msg ChanServ SOP #canal ADD usuario     # Super-op

# Anope - Sistema ACCESS (numérico)
/msg ChanServ ACCESS #canal ADD usuario 10   # Nivel 10 = voice típico
/msg ChanServ ACCESS #canal ADD usuario 100  # Nivel 100 = op
/msg ChanServ ACCESS #canal ADD usuario 500  # Nivel 500 = founder

# Anope también soporta FLAGS al estilo Atheme
/msg ChanServ FLAGS #canal usuario +voAt

Mi preferencia personal es el sistema de FLAGS de Atheme. Es más explícito y granular. El sistema XOP de Anope es más fácil de entender para usuarios nuevos, pero los niveles numéricos son confusos cuando necesitas permisos intermedios.

Bases de datos y persistencia

Aspecto	Atheme	Anope
Formato nativo	Flatfile / OpenSEX	Flatfile
SQL	Módulo opcional (PostgreSQL)	Nativo (MySQL, PostgreSQL, SQLite)
Backup	Copia del archivo .db	Copia del archivo .db o dump SQL
Migración entre formatos	Herramientas incluidas	Herramientas incluidas
Rendimiento (>10k cuentas)	Excelente (flatfile en RAM)	Bueno (depende del backend SQL)

El formato OpenSEX de Atheme (sí, se llama así — Open Services Exchange) es un flatfile humanamente legible. Puedes abrirlo con un editor de texto y ver las cuentas, canales y metadatos. Esto es extremadamente útil para debugging.

# Fragmento de un archivo OpenSEX de Atheme:
MU marco $6$rounds=6000$salt$hash marco@email.com 1704067200 1704153600 +sE default
MN marco marco_ 1704067200 1704153600
MC #irc6 1704067200 1704153600 +ntsi
CA #irc6 marco +vVoOtsirf 1704067200 marco

Consejo: Independientemente de qué servicios uses, automatiza los backups de la base de datos. Yo hago un backup cada 6 horas y mantengo 7 días de retención. Perder la base de datos de servicios significa que todos tus usuarios pierden sus nicks y canales registrados. Es el dato más valioso de tu red.

¿Cuál elegir?

Mi recomendación basada en escenarios reales:

Red nueva, pocos operadores técnicos → Anope. La documentación es mejor, la comunidad más grande, y BotServ es un extra que los usuarios aprecian.
Red técnica, usuarios avanzados → Atheme. El modelo de cuentas es más limpio, FLAGS es más potente, y el bajo consumo de recursos escala mejor.
Migración desde servicios antiguos → Ambos tienen herramientas de importación. Anope importa desde más formatos legacy.
Integración con SASL obligatoria → Atheme tiene mejor integración SASL históricamente, pero Anope ya está a la par.
Necesitas BotServ → Anope. No hay alternativa en Atheme.
Necesitas SQL obligatoriamente → Anope. El soporte SQL es nativo y de primera clase.

En mis redes actuales uso Atheme. No porque sea objetivamente superior, sino porque me siento más cómodo con su configuración y porque el modelo de FLAGS encaja mejor con cómo gestiono los canales. Pero si mañana montara una red orientada a usuarios no técnicos, probablemente elegiría Anope por BotServ y la documentación.

Preguntas frecuentes

¿Puedo migrar de Atheme a Anope (o viceversa)?

Sí. Anope puede importar bases de datos de Atheme directamente. La migración en sentido contrario (Anope a Atheme) es más manual — necesitas exportar los datos relevantes y usar scripts de conversión. En ambos casos, haz la migración en un entorno de prueba antes de tocar producción. He visto migraciones que pierden metadatos de canales o flags específicos.

¿Atheme funciona con InspIRCd?

Sí. Atheme soporta múltiples protocolos de enlace: UnrealIRCd 4/5/6, InspIRCd 2/3/4, Charybdis, ircd-seven y otros. El módulo de protocolo se selecciona en la configuración. La funcionalidad es la misma independientemente del IRCd que uses, aunque algunos modos de canal específicos del IRCd pueden requerir módulos adicionales en Atheme.

¿Los servicios necesitan un servidor dedicado?

No. Los servicios se conectan al IRCd como un server link. Pueden correr en la misma máquina que el IRCd sin problemas. De hecho, es lo más común en redes pequeñas y medianas. Los servicios consumen poca RAM y CPU — un VPS con 512 MB puede correr IRCd + servicios + ZNC sin sudar. Solo en redes con decenas de miles de cuentas empezarías a pensar en separar los servicios a otra máquina.

¿Qué pasa si los servicios se caen?

Los usuarios no pueden registrar nicks ni canales, ni cambiar permisos, ni usar SASL. Pero los canales y nicks existentes siguen funcionando — los modos ya aplicados persisten hasta un netsplit. Lo que pierdes es la capacidad de gestión. En Atheme, si configuras enforce, los nicks dejan de estar protegidos temporalmente. Al reconectar los servicios, todo vuelve a la normalidad y la base de datos se sincroniza.