En MindTheClub, el contenido de los mensajes viaja directamente entre dos dispositivos por un canal peer-to-peer cifrado. Ningún servidor de MindTheClub, ni ningún tercero, almacena el contenido de tus mensajes.
Para establecer esa conexión directa, dos dispositivos necesitan intercambiar una pequeña cantidad de información de configuración y, si uno de ellos está dormido, una señal para despertarlo. Esos dos pasos de apoyo son los únicos lugares donde interviene un servidor, y a continuación describimos con precisión qué puede ver cada uno y qué no.
Antes de que ocurra nada de eso, los dos dispositivos necesitan conocer la identidad del otro. Lo describimos primero, porque cada paso posterior de esta página se apoya en ello.
Cada paso cifrado que sigue se apoya en una suposición: cada par usa la clave pública real del otro, no una sustituida por un proveedor intermedio. Lo conseguimos con un único intercambio fuera de banda y una respuesta sellada, de modo que ambas partes quedan verificadas tras un escaneo de QR o un toque en un enlace de invitación.
Tu código QR contiene tu identificador de usuario y una huella digital de tu clave pública, un hash criptográfico corto que la identifica de forma única. Tu enlace de invitación lleva las mismas dos cosas, incrustadas en el propio enlace. Así, tanto si alguien escanea tu código como si toca tu enlace, su dispositivo recibe la misma huella para comprobar. Mostrar el QR cara a cara es el canal más fuerte, pero en ambos casos se cumple la garantía siguiente: el proveedor del directorio nunca puede sustituir tu clave sin ser detectado.
Cuando la otra persona escanea o toca, su dispositivo obtiene tu clave pública del directorio y calcula su huella localmente. Si coincide con la del QR o el enlace, la clave se acepta; si no, se rechaza y no se guarda. Una clave sustituida produce una discrepancia, y el dispositivo la rechaza.
Su dispositivo te envía entonces una solicitud de contacto con su propia huella sellada dentro, cifrada con tu clave verificada. Solo tú puedes descifrarla. Tu dispositivo ejecuta la misma comprobación a la inversa y acepta el contacto solo si las huellas coinciden.
Tras un escaneo o un toque, ambos pares han verificado de forma independiente la clave del otro, y un proveedor que mantenga el directorio no puede sustituir ninguna de las dos sin romper una comprobación que no tiene poder de falsificar.
MindTheClub usa canales de datos WebRTC para transportar los mensajes. Un canal de datos WebRTC es una conexión directa y cifrada entre dos dispositivos. Una vez establecido entre dos pares:
Los archivos grandes se dividen en bloques y se envían por el mismo canal directo, con lógica de reintento en el dispositivo emisor para garantizar la entrega final. Los bloques viajan peer-to-peer como todo lo demás.
A veces dos dispositivos no pueden abrir una ruta directa (NAT restrictivas, cortafuegos de operadoras móviles). En ese caso WebRTC recurre a un relé TURN para hacer pasar el flujo cifrado. MindTheClub usa el servicio TURN de Cloudflare para este plan alternativo. El relé reenvía paquetes cifrados; es una parte estándar del funcionamiento de WebRTC cuando la conexión directa no es posible. Este mecanismo solo afecta a la ruta de red del flujo cifrado; no cambia el hecho de que el contenido va de extremo a extremo entre los dos dispositivos.
Antes de que un canal WebRTC pueda abrirse, los dos dispositivos deben intercambiar información de «señalización»: descripciones de conexión y direcciones de red candidatas (en términos de WebRTC, la oferta/respuesta SDP y los candidatos ICE). Es un requisito universal de WebRTC: toda aplicación WebRTC, incluidas las webs de videollamadas, lo hace. La información es pequeña y solo se necesita para establecer la conexión; no es el contenido de tus mensajes.
La cuestión es quién transporta esa señalización y qué puede ver. En MindTheClub:
Diseñamos la señalización para que el relé aprenda lo mínimo posible:
Si el teléfono de Bob está dormido o la app no se está ejecutando, el dispositivo de Alice necesita una forma de despertarlo para que se una a la conexión. Para ello, MindTheClub usa Firebase Cloud Messaging (FCM), el servicio push de Google, porque es el mecanismo que Android proporciona para despertar una app de forma fiable desde segundo plano.
El contenido de la carga de despertar se cifra con la clave pública del destinatario antes de salir del remitente. Y lo crucial: la identidad del remitente va dentro de esa carga cifrada; no es visible para la infraestructura push. Es un diseño de «remitente sellado»: la parte que entrega el push no puede ver quién lo envió.
Para entregar un push, cualquier sistema push necesita saber quién lo recibe; así funciona la entrega, y ocurre en todos los mensajeros basados en push. Por tanto, la dirección del destinatario es necesariamente visible para la capa push. Lo que no es visible es la identidad del remitente, que permanece sellada dentro de la carga cifrada.
Para establecer la conexión WebRTC, los dispositivos necesitan credenciales de corta duración para el servicio STUN/TURN (los componentes que ayudan a dos dispositivos a encontrar una ruta de red entre sí). Estas credenciales se generan con una clave secreta que debe mantenerse fuera del dispositivo.
MindTheClub obtiene estas credenciales de un Cloudflare Worker que guarda el secreto en el lado del servidor. Ningún servicio de Google interviene en la obtención de las credenciales de conexión. Si esta petición falla, la conexión recurre a servidores STUN públicos, que solo ayudan a un dispositivo a descubrir su propia dirección pública y no aprenden nada sobre con quién va a contactar.
Uniéndolo todo: los pares verifican mutuamente sus claves con un escaneo de QR o un enlace, y luego intercambian pequeñas cantidades de información de configuración cifrada a través de un relé sin estado y un push de despertar sellado. Una vez abierto el canal directo, el contenido de los mensajes fluye únicamente de dispositivo a dispositivo.