Qué cruza entre servidores

Los nodos se hablan entre sí en mensajes firmados, un mensaje por evento. Cada mensaje lo firma el nodo que lo envía y lo comprueba el nodo que lo recibe antes de hacer nada con él. Un mensaje que no pasa la comprobación se rechaza, y un mensaje que ya se ha visto antes se vuelve a rechazar — un nodo guarda un registro de cada mensaje que ya ha aceptado.

Todo lo que sigue es lo que contienen esos mensajes. Nada más viaja.

Encontrar a una persona

Un nodo publica una respuesta de descubrimiento para cada una de sus personas. Pregúntale por un identificador y devuelve el identificador de esa persona, su servidor de origen, su clave pública de identidad, y las versiones de protocolo que habla el nodo. La respuesta va firmada.

Eso es toda la respuesta. Ni correo electrónico, ni puntuación de confianza, ni número de conexiones, ni nombre. Cualquiera que conozca el identificador puede leer esa respuesta, no solo otros nodos.

Si el identificador no existe, el nodo lo dice — y también lo firma, para que una red intermedia no pueda inventar una respuesta de que una persona ha desaparecido.

El descubrimiento se puede desactivar, en cuyo caso el nodo queda a oscuras y los demás nodos no pueden resolver a nadie en él.

Buscar un código

Cuando alguien verifica un código que pertenece a una persona de otro nodo, las palabras en sí no viajan. Solo viaja un hash de ellas.

Responde el nodo que es dueño del código. Según lo que se haya pedido, la respuesta es un simple sí o no, o — cuando hay coincidencia — los detalles que lo acompañan: el nombre y la foto de quien es dueño del código, cómo se etiquetó el código y para qué era, cuándo deja de ser válido, su puntuación de confianza y los recuentos de los que se construye, y la organización a la que pertenece el código cuando la hay. Nada más sobre la persona se envía.

Un código de invitado de un solo uso se gasta exactamente una vez aunque lleguen varias solicitudes en el mismo momento; a las que pierden la carrera se les dice que el código ya está consumido. Un faro se responde de la misma manera pero nunca se gasta, porque es una comprobación de actividad y no un código de un solo uso.

Si el dueño de un faro ha decidido mostrar su correo electrónico en él, esa dirección forma parte de la respuesta del faro. Eso es un ajuste que cada persona activa para sí misma, y está desactivado a menos que lo haga.

El nodo que es dueño del código registra quién preguntó.

Invitaciones

Una invitación enviada a alguien de otro nodo lleva las claves públicas de identidad de las dos personas, el nombre visible de quien invita, una referencia a la conexión en el nodo que invita, y el mensaje de invitación cifrado.

El nodo que la recibe la deja pendiente. No crea una cuenta ni crea una conexión. No existe nada del lado de la persona invitada hasta que ella misma acepta.

Hay un caso en el que una invitación lleva un correo electrónico: cuando un miembro de un nodo invita a alguien que no tiene cuenta en ningún sitio y el nodo no puede crear cuentas por sí mismo. El nodo entonces ofrece la invitación a trusted.codes, y el correo electrónico de la persona invitada va con ella, para que pueda registrarse ahí. Ese comportamiento es un ajuste, está desactivado a menos que el operador lo active, y el lado receptor también tiene que aceptar ofertas de tu nodo. Consulta Node Settings en tu nodo para ambas mitades.

Secretos de conexión

El material que produce los códigos que ven dos personas lo envuelve el dispositivo de la persona que envía para el dispositivo de la persona que recibe. Pasa por los dos servidores como un bloque opaco. Ningún servidor puede abrirlo.

Las dos personas ven códigos que coinciden porque sus dispositivos los derivan de ese secreto compartido. Cada servidor también guarda su propio valor independiente para su propia contabilidad local; de ese valor no salen los códigos.

El nombre de la conexión viaja cifrado.

Cambios de membresía

Cuando alguien se une a una conexión, la deja, o la conexión se elimina, se avisa al otro nodo. Cuando alguien elimina su cuenta, su nodo lo anuncia y cada uno de los demás nodos quita lo que tenía sobre esa identidad. Cuando se quita un dispositivo, la baja se anuncia para que los demás nodos dejen de confiar en la clave de ese dispositivo.

Un nodo también puede preguntarle a otro nodo si una conexión que refleja sigue existiendo y si ciertas personas siguen en ella. Solo puede preguntar por personas que ya nombra. El listado nunca se devuelve completo, y a un nodo que no forma parte de esa conexión no se le dice nada en absoluto.

Notificaciones push

Un nodo que lleva sus propios usuarios sigue sin poder enviar directamente a Apple y Google — las credenciales de la aplicación móvil compartida no son del operador. Así que un nodo le entrega los tokens del dispositivo a trusted.codes para que los envíe.

El relevo lleva los tokens y el tipo de aviso, nada más. No hay título ni cuerpo. El dispositivo se despierta, le pide los datos reales a su propio servidor de origen, y los muestra localmente. Si el relevo falla, no se rompe nada; la aplicación se pone al día la próxima vez que se abre.

Lo que nunca sale

Cuentas, contraseñas y sesiones. La base de datos en sí. El texto plano de un código. El contenido de una bóveda. El nombre y el correo electrónico de cualquiera que no haya formado parte de un intercambio.

Cualquier clave que el operador haya proporcionado para servicios opcionales — geolocalización, IA, los paneles de control — pertenece a ese despliegue. Nadie más las ve.