lnchat: crea tu propio protocolo de chat federado

Por qué la federación vuelve a estar sobre la mesa

Un solo archivo .well-known y dos endpoints bastan para que un servidor se sume a una red de mensajería sin pedirle permiso a ninguna autoridad central. Ese es el punto de partida de lnchat, el protocolo federado que el desarrollador karboosx documentó paso a paso en su blog, y funciona como un ejercicio de arquitectura que conviene leer antes de decidir si tu producto necesita infraestructura descentralizada.

En vez de montar un orquestador central que reciba solicitudes de ingreso y las distribuya, el enfoque federado hace que los servidores se hablen entre sí directamente. Si alguna vez pensaste que tu producto debería ser descentralizado, este caso sirve para medir el costo real de esa decisión antes de escribir la primera línea de código.

Qué es la federación y en qué se parece al correo

El mejor ejemplo es SMTP, el protocolo con el que viaja el email. Es un sistema casi descentralizado: cualquiera puede levantar su propio servidor de correo y no existe una autoridad única que decida qué servidor puede enviar mensajes y cuál no. Cada servidor se comunica con los demás usando un protocolo conocido e intercambia información de servidor a servidor. El autor lo describe como una API con esquemas de payload conocidos, aunque admite que es una simplificación.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Ahí aparece la primera pista de diseño: la arroba. Una dirección como [email protected] incluye el dominio porque hace falta saber qué dominio responde por esa identidad. Cuando [email protected] le escribe a [email protected], el servidor de envío toma la parte y.com, hace un descubrimiento de registros MX por DNS, se conecta con el servidor responsable de ese dominio y recién entonces empieza el intercambio de mensajes.

La federación es exactamente eso: servidores que se hablan directo después de un proceso de descubrimiento. Cambia el método de descubrimiento (DNS en el correo, un archivo público en lnchat), pero la lógica de fondo es la misma.

Los tres requisitos que definen el protocolo

Antes de escribir código, el autor fija el alcance. Son tres condiciones y cada una tiene consecuencias directas en la arquitectura:

Cifrado de extremo a extremo: el servidor solo ve datos cifrados, y son los clientes los que manejan el cifrado y el descifrado.
Verificación de origen: no se puede confiar en cualquiera que llegue por HTTP diciendo que es x.com. Hace falta comprobar que la petición la firmó un servidor que controla el dominio de origen.
Alcance acotado: sin adjuntos, sin multi-dispositivo, sin grupos ni confirmaciones de lectura. Solo texto y un dispositivo. El autor lo resume con un guiño: bienvenido a los 90.

Esa tercera decisión es la que vuelve viable el ejercicio. Un protocolo que intenta cubrir todo desde el día uno nunca termina de definirse. Acotar el conjunto mínimo de capacidades es una lección que aplica a cualquier MVP, no solo a infraestructura de comunicaciones.

Identidad: cada usuario cuelga de un dominio

Como la federación necesita saber a qué servidor llamar, la identidad tiene que adoptar la forma <nickname>@<dominio>. El detalle importante es que eso no es una dirección de email: solo usa la misma forma porque la forma resulta útil, ya que el dominio le indica a los demás servidores dónde encontrar los metadatos de federación.

El autor aclara que el formato es una decisión libre. x.com > adam, x.com#adam o adam on x.com funcionarían igual. Lo que no se puede negociar es que exista un dominio en la identidad.

Descubrimiento: el archivo que publica cada servidor

El primer requisito real de lnchat es un archivo en la ruta conocida GET /.well-known/lnchat.json, que en su versión mínima solo declara el protocolo y su versión (lnchat.federation.v1). Versionar un protocolo siempre es buena práctica: fija el contrato y evita dolores de cabeza cuando el formato evoluciona.

Con ese archivo, cualquier servidor puede comprobar si el servidor al que quiere escribir soporta el protocolo y de dónde sacar el resto de la información. Después se agrega un bloque de endpoints con rutas propias para resolver usuarios y enviar mensajes. La razón es concreta: forzar rutas fijas puede chocar con rutas que ya existen en el servidor. Dejar que cada servidor publique sus propias URLs es más flexible y menos invasivo.

Cifrado de extremo a extremo sin confiar en el propio servidor

El cifrado se apoya en dos claves: una privada que se queda en el cliente y una pública que el servidor del usuario comparte con otros servidores. La pública la usan los emisores para cifrar y la privada la usa el receptor para descifrar.

La regla es tajante: la clave privada nunca debe enviarse al servidor en texto plano. Si el servidor puede leerla, puede leer los mensajes, y el cifrado de extremo a extremo deja de existir. En el ejemplo, el usuario genera el par de claves con la Web Crypto API del navegador y el servidor solo guarda la clave pública en su base de datos.

El endpoint de resolución de usuarios devuelve, para cada usuario, un key_id y su public_key, y acepta una lista de usuarios en lugar de uno solo para reducir la cantidad de llamadas HTTP en servidores con volumen alto. Los estados posibles son ok y not_deliverable: el segundo cubre el caso de usuarios que todavía no generaron claves y por lo tanto no pueden recibir mensajes cifrados.

El key_id no es decorativo. Si el cliente cachea una clave pública y esa clave cambia, el receptor nunca podrá descifrar el mensaje. El identificador permite distinguir claves entre sí y hasta mostrar una advertencia de que la clave cambió.

El propio autor agrega una advertencia que muchos productos ignoran: si el servidor es el responsable de publicar las claves públicas, un servidor malicioso o comprometido podría mentir sobre una clave. El cifrado de extremo a extremo real necesita alguna forma de detectarlo, por ejemplo advertencias de cambio de clave, huellas, TOFU (Trust On First Use, confiar en la primera vez) o transparencia de claves.

Cómo viaja un mensaje de un servidor a otro

El reparto de responsabilidades del protocolo es simple y vale la pena copiarlo como modelo:

El cliente cifra el cuerpo del mensaje.
El servidor de origen valida la petición, arma el sobre de federación y lo envía al servidor del destinatario.
El servidor receptor valida el mensaje y lo guarda hasta que el usuario lo pida.
El usuario descifra con su clave privada.

El cliente envía a su propio servidor el destinatario, el recipient_key_id, la clave encapsulada y el texto cifrado. El servidor agrega dos campos que el cliente no puede definir: el sender y el message_id. El remitente lo pone el servidor porque el usuario ya está autenticado, y el identificador existe por idempotencia: si el mismo mensaje llega dos veces, la segunda se rechaza. El autor sugiere generarlo con UUIDv7, un identificador aleatorio con componente temporal.

HPKE: por qué el payload tiene dos partes

HPKE (Hybrid Public Key Encryption, o cifrado híbrido de clave pública) explica por qué el mensaje viaja en dos piezas. Cifrar directamente con claves asimétricas es computacionalmente caro, así que el modelo simplificado es:

Se genera una clave simétrica nueva, del tipo que cifra y descifra con la misma llave.
Se cifra el mensaje con esa clave simétrica.
Se encapsula la clave simétrica usando la clave pública del destinatario y se envía junto al mensaje.
El receptor recupera la clave simétrica y con ella descifra el mensaje.

De ahí salen los campos encapsulated_key y ciphertext. Para implementarlo en JavaScript, el autor recomienda no escribir criptografía propia y usar librerías mantenidas por terceros, como hpke-js.

Firma de servidor: la prueba de que el mensaje viene de x.com

Sin este punto, el protocolo se cae. Cualquiera puede enviar una petición HTTP con un JSON que diga sender: [email protected]: eso no prueba nada. Por eso las peticiones de federación deben ir firmadas por el servidor emisor.

El detalle crítico es que se trata de un par de claves distinto del de los usuarios. Las claves de usuario son para el contenido; las claves de servidor, para demostrar que una petición de federación salió de un servidor específico. El autor recomienda explícitamente no mezclarlas.

El servidor publica su clave pública en el archivo de descubrimiento, y cada petición lleva cabeceras con el dominio de origen, el dominio destino, el identificador de clave, un timestamp, un identificador de petición, el hash del cuerpo y la firma. Se firma el hash del cuerpo y no el cuerpo completo, porque firmar es más rápido que cifrar y no hace falta procesar megabytes para eso. El timestamp y el identificador de petición son los que permiten rechazar peticiones viejas o repetidas.

El párrafo que más problemas evita en producción es el de la cadena canónica. Ambos servidores deben construir exactamente el mismo texto: los mismos saltos de línea, la misma ruta, el mismo formato de fecha y el mismo hash. Si uno firma una cadena ligeramente distinta de la que el otro verifica, la verificación falla. Firmar la versión, el método HTTP y la ruta evita que una petición firmada para un endpoint se reutilice en otro.

Hay además una nota de seguridad que aplica a cualquier integración entre servidores: hay que evitar el SSRF (Server-Side Request Forgery), el ataque en el que un servidor remoto engaña al tuyo para que llame a direcciones internas o de red privada. Al descargar el archivo de descubrimiento, hay que validar el dominio de origen, exigir HTTPS con certificados válidos y no seguir redirecciones hacia redes privadas o locales.

Qué significa esto para tu startup

Puede que nunca construyas un protocolo de mensajería, pero el patrón de lnchat se repite en cualquier sistema que hable con terceros: integraciones, webhooks, APIs entre socios.

Copia las tres piezas del contrato. Un archivo de descubrimiento versionado, firma sobre una cadena canónica y un identificador de petición para idempotencia. Son baratas de implementar al principio y carísimas de agregar después, cuando ya tienes clientes integrados.
No escribas criptografía propia. Genera claves en el cliente, guarda la privada como objeto no extraíble en el navegador y delega el resto en librerías auditadas. El ejemplo usa la Web Crypto API del navegador y node:crypto del lado del servidor.
Diseña la rotación de claves desde el día uno. El key_id existe justamente para poder rotar una clave sin romper a los clientes que tienen la anterior en caché. Si tu modelo de claves no distingue versiones, no puedes rotar sin incidentes.
Pregúntate si de verdad necesitas federar. El propio autor aclara en los comentarios del post que en la vida real probablemente nadie tenga que construir algo así, que en el mercado existen pocos protocolos realmente descentralizados y que, si necesitas uno, conviene adoptar algo ya establecido. Su objetivo con el artículo es entender cómo funciona por dentro, no producir un protocolo para producción.

Conclusión

lnchat no pretende competir con nada: es un ejercicio que muestra, con código, qué implica de verdad federar. Identidad atada a un dominio, descubrimiento mediante un archivo público, claves de usuario que nunca tocan el servidor y claves de servidor que firman cada petición. Cada una de esas piezas responde a un problema concreto, y ese mapeo entre problema y decisión de diseño es lo más aprovechable del artículo.

Para un founder, la conclusión práctica es incómoda pero útil: construir tu propio protocolo es un proyecto de años, no de un sprint, y la mayoría de los productos que quieren ser descentralizados en realidad solo necesitan interoperabilidad bien documentada. Si vas a intentarlo, que sea con el alcance recortado que propone el autor.

No se encontraron datos adicionales verificables en la búsqueda realizada para ampliar el contexto de mercado de este artículo.