¿Por qué no usamos Matrix?
Matrix es un gran protocolo. Aun así, elegimos construir algo propio, más simple y ligero. Aquí te explicamos por qué.
Evaluamos Matrix (mensajería federada con cifrado Olm/Megolm) y lo descartamos a favor de una implementación propia. Sus fortalezas —federación madura, forward secrecy, verificación de dispositivos— vienen con una complejidad y un peso que no encajan con nuestros tres objetivos: simple de auto-hospedar, fácil de auditar y estrictamente zero-knowledge en el nodo.
Matrix frente a LOOKLOCK
| Aspecto | Matrix | 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 guarda 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 homeserver Matrix necesita PostgreSQL y bastante RAM/CPU. Nuestro nodo es un único fichero Python sin dependencias que corre en el VPS más barato. Es la clave de «trae tu propio nodo».
2. Cifrado más simple
Matrix usa Olm/Megolm (Double Ratchet + claves de grupo con estado, device keys, cross-signing): potente pero complejo y con los típicos fallos de «no se puede descifrar». Nosotros ciframos cada mensaje una vez por la clave pública de cada miembro. Sin estado de sesión, sin rotación de clave de sala. Más fácil de auditar.
3. Menos metadatos
La federación de Matrix 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 guarda 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 por conversación, salas, cuentas de empresa) sin atarnos a la especificación ni al calendario de Matrix.
Con honestidad: a qué renunciamos
Matrix hace muy bien tres cosas: forward secrecy (ratchet de Megolm), verificación de dispositivos y federación madura. Con nuestro modelo no tenemos forward secrecy por defecto. Es una decisión consciente a favor de la simplicidad y el auto-hospedaje. El Double Ratchet queda anotado como posible mejora futura, sin cambiar el resto de la arquitectura.