¿Por qué no reutilizamos un protocolo federado ya existente?

Los protocolos federados que ya existen están bien hechos. Aun así elegimos construir algo propio, más simple y ligero. Aquí explicamos por qué.

Evaluamos los protocolos de mensajería federada más maduros y los descartamos a favor de una implementación propia. No por soberbia: por peso, por control del ritmo y por metadatos.

Un protocolo federado maduro frente a LOOKLOCK

Aspecto Protocolo federado LOOKLOCK
Servidor Homeserver pesado (Synapse/Dendrite) + PostgreSQL Un fichero Python (~11 KB), sin dependencias
Cifrado de grupo Olm/Megolm: potente pero con estado y «unable to decrypt» ECIES fan-out: una copia por miembro, sin estado de sala
Metadatos La federación replica eventos y expone membresías/relaciones Central = directorio; el nodo solo custodia sobres cerrados
Auto-hospedaje Requiere recursos y mantenimiento Cualquiera levanta su nodo en un VPS barato en minutos

Las razones, una a una

1. Peso del servidor

Un servidor de esos protocolos necesita una base de datos completa y bastante RAM y CPU. Nuestro nodo es un único fichero Python sin dependencias: cabe en una Raspberry Pi.

2. Cifrado más simple

Usan criptografía de grupo con estado (claves de dispositivo, firma cruzada): potente, pero mucha superficie que mantener y auditar para lo que necesitamos.

3. Menos metadatos

La federación replica eventos entre servidores y expone metadatos (quién habla con quién, membresías, estado de sala). En LOOKLOCK la central es solo un directorio y el nodo custodia sobres cerrados que no puede abrir.

4. Control e independencia

Una implementación propia nos deja evolucionar a nuestro ritmo (registro por invitación, nodo propio, mensajes efímeros) sin esperar a un estándar ajeno.

Con honestidad: a qué renunciamos

Para ser justos: esos protocolos hacen muy bien tres cosas que nosotros aún no igualamos: forward secrecy, verificación de dispositivos y un ecosistema de clientes enorme. Lo decimos aquí porque preferimos que lo sepas por nosotros.