Cómo funciona
Chat WebRTC peer-to-peer, explicado
Después del handshake no hay ningún servidor en el camino, así que no hay nada que guardar ni nada que entregar. Acá está exactamente lo que ve el backend, y las tres cosas que el peer-to-peer no te garantiza.
Abrir una sala P2P
Abrir una sala P2PEl único trabajo del servidor es la presentación
Todas las apps de chat que usaste funcionan igual por debajo: tu mensaje sube al servidor de una empresa, el servidor lo guarda y se lo entrega a la otra persona. Las discusiones sobre cifrado son sobre quién puede leer esa copia. La copia sigue existiendo.
Un DataChannel de WebRTC se salta ese paso intermedio. Dos navegadores negocian una conexión cifrada directa, y una vez que está abierta tu mensaje va de tu máquina a la del otro sin nada en el medio. FadeChats sí corre un servidor, pero funciona como un operador de conmutador: pasa los datos que los dos navegadores necesitan para encontrarse, y después queda fuera de la conversación.
Ese es todo el truco, y por eso este sitio no tiene un botón de "borrar mis datos". No hay ninguna tabla de mensajes de la cual borrar.
Qué pasa entre que abrís la página y empezás a escribir
- Tu navegador escribe una oferta
Arma una oferta SDP que describe el transporte que soporta, más la huella de un certificado que generó para esta sesión. La oferta va al servidor de FadeChats, guardada bajo un id de sala aleatorio.
- El otro navegador responde
Tu invitado abre el enlace de invitación de un solo uso, recoge la oferta y envía una respuesta. Los dos lados también intercambian candidatos ICE: las direcciones de red donde cada uno podría ser alcanzable, descubiertas con la ayuda de un servidor STUN.
- Los dos extremos se dan la mano directamente
ICE prueba pares de candidatos hasta que uno conecta, y ahí los navegadores corren un handshake DTLS sobre esa conexión. Derivan las claves ellos mismos y se verifican contra las huellas comprometidas en el primer paso.
- El canal se abre, el servidor termina su trabajo
Texto, imágenes, GIFs y stickers viajan por un stream SCTP dentro de esa sesión DTLS, de navegador a navegador. Los registros de configuración expiran con un TTL de 10 minutos que la actividad renueva.
Quién puede ver qué
| La persona que invitaste | El servidor de FadeChats | Un relay TURN, cuando hace falta | |
|---|---|---|---|
| Mensajes, imágenes, GIFs | Sí, esa es la idea | Nunca | Solo bytes cifrados |
| El id de la sala | Sí | Sí | Sí |
| Tu dirección IP | Sí, en una conexión directa | Sí, durante la configuración | Sí, mientras retransmite |
| Que la sala estuvo activa | Sí | Hasta que expira el TTL | Mientras retransmite |
| Algo después de que la sala desaparece | Solo lo que haya capturado | Nunca se escribió nada | Nada |
Que cada lado conozca la dirección del otro es una propiedad del transporte, no una opción que se pueda desactivar.
Tres cosas que el peer-to-peer no te garantiza
- Tu contraparte ve tu dirección IP
Una conexión directa tiene dos extremos reales, así que la persona que invitaste se entera más o menos de tu ciudad y tu proveedor de internet. Signal lo esconde retransmitiendo todo a través de sus propios servidores. FadeChats no puede, porque retransmitir todo es justo lo que se niega a hacer.
- A veces hay un relay de todos modos
El NAT simétrico, las redes corporativas y algunos operadores móviles bloquean el camino directo. Ahí WebRTC recurre a un relay TURN, que reenvía bytes cifrados con DTLS sin tener la clave para leerlos. Igual es una tercera máquina en el camino, y vale la pena decirlo claramente.
- El handshake confía en el canal de señalización
Cada lado verifica la huella del certificado del otro, pero esa huella llegó a través del servidor. Un servidor de señalización comprometido podría en principio cambiarla y meterse en el medio. Signal resuelve esto con números de seguridad que comparás por otro canal; FadeChats no tiene esa verificación.
Dónde encaja este modelo
El peer-to-peer tiene sentido cuando dos personas necesitan decir algo una vez y no quieren que quede copia en ningún lado: una contraseña con una pregunta de seguimiento, una dirección, un diagnóstico, un número. No es el modelo correcto para un grupo, para nada que tenga que sobrevivir a una pestaña cerrada, ni para una situación donde equivocarte sobre tu adversario tiene consecuencias reales.
Preguntas frecuentes
¿Un chat por WebRTC necesita un servidor?
Sí, pero solo para presentar a los dos navegadores. Un servidor de señalización lleva la oferta, la respuesta y los candidatos de red; un servidor STUN le dice a cada navegador cómo se ve su dirección pública. Una vez que el DataChannel se abre, ninguno de los dos queda en el camino de un solo mensaje.
¿El servidor de señalización puede leer mis mensajes?
No, nunca los recibe. El canal se negocia entre los navegadores y las claves son de ellos. El servidor de FadeChats solo guarda los registros de configuración, y esos expiran con un TTL de 10 minutos que la actividad renueva.
¿La otra persona ve mi dirección IP?
En una conexión directa, sí, y vos también ves la de ella. Eso es justo lo que la hace directa. Si necesitás ocultarla de la persona con la que hablás, usá una VPN, o una herramienta que retransmita todo, como Signal.
¿Un DataChannel de WebRTC está cifrado de extremo a extremo?
El transporte sí lo está: SCTP dentro de DTLS, con claves que los dos navegadores derivan ellos mismos. La salvedad es el intercambio de huellas explicado arriba. El cifrado de extremo a extremo en WebRTC es tan confiable como el canal que llevó esas huellas.
¿Necesito instalar algo para probarlo?
No. WebRTC viene incluido en todos los navegadores actuales, así que FadeChats es solo una página que abrís. Sin cuenta, sin número de teléfono, sin app. La sala existe cuando carga la página y tiene lugar para dos personas.