Trystero - crea webapps multijugador instantáneas sin servidor

 (github.com/dmotz)
36 puntos por xguru 2025-10-27 | 8 comentarios | Compartir por WhatsApp
  • Una librería que permite implementar webapps multijugador interconectadas entre sí sin servidor con solo unas cuantas líneas de código
  • Basada en WebRTC del navegador, usa redes públicas como canal de intercambio de señales (signaling) para automatizar el emparejamiento P2P y la comunicación
    • Permite realizar descubrimiento de pares sin servidor eligiendo entre BitTorrent, Nostr, MQTT, IPFS, Supabase, Firebase
    • Después del signaling, los datos de la app se transmiten directamente por P2P con cifrado E2E, sin pasar por un medio intermedio
  • Ofrece abstracciones de alto nivel como Rooms/broadcasting, serialización automática, chunking/throttling de datos grandes, eventos de progreso, cifrado de datos de sesión y metadatos de streams
  • Funciona no solo en el navegador, sino también en Node/Deno/Bun, y soporta funciones prácticas como configuración de servidores TURN, hooks de React y ejecución del lado del servidor
  • Su enfoque de aprovechar infraestructura pública sin configuración lo hace ideal para distintos experimentos y prototipado

Lecturas relacionadas

8 comentarios

 
kimjoin2 2025-10-27

¿El servidor TURN te lo proveen los ancestros?
 
helio 2025-10-28

Parece que 'stun:stun.cloudflare.com:3478' está incrustado en el código fuente.
 
kimjoin2 2025-10-28

No stun, sino turn.
stun solo sirve, en términos simples, para decir quién eres según stun, así que hay algunos servidores públicos,
pero turn tiene que retransmitir el tráfico (o sea, es caro), así que hay que pagar por usarlo o montarlo por cuenta propia.
Ej.) https://github.com/coturn/coturn
Es algo de este estilo.

Es cierto que en muchos casos se puede comunicar solo con stun, pero decir simplemente que “funciona” es...
funcionar, funciona... pero mmm... esa es la sensación.
 
skageektp 2025-10-29

Si es emparejamiento P2P, ¿no haría falta TURN?
 
kimjoin2 2025-10-29

Creo que depende de a qué te refieras con “emparejamiento p2p” en WebRTC.

  1. Un estado en el que ambos pueden comunicarse con paquetes por UDP
  2. Un estado en el que ambos solo conocen la dirección que les informa STUN

Si es el caso 1, como dices, no hace falta TURN.
Incluso en el caso 2, si la situación es favorable y la comunicación UDP entre ambos tuvo éxito, no hace falta TURN.

En el caso 2, si falla la comunicación de paquetes por UDP entre ambos, ahí sí hace falta TURN.

Las causas del fallo pueden ser:

  • que el peer esté detrás de un NAT simétrico, por ejemplo, y no se pueda usar la dirección (o el puerto) que descubrió STUN, o
  • que en algún punto intermedio de la red solo se permita tráfico web (80, 443), o
  • que en algún punto intermedio de la red esté bloqueado UDP, o
  • que un lado use solo IPv4 y el otro solo IPv6, o
  • etc.

En esos casos hay que usar TURN.

(Recién me entero, al revisar este recuerdo, de que IPv4 only <-> IPv6 only no funciona.)
 
skageektp 2025-10-30

Sí, o sea, la opción 2. Dijeron "interoperar entre sí sin servidor" y "biblioteca", pero quizá están esperando demasiado...
 
kimjoin2 2025-10-30

¿A qué parte te refieres exactamente?

  1. Como es posible conectarse solo con la dirección (+puerto) que te indica STUN, no hace falta un servidor TURN. Por lo tanto, la expresión "conectarse entre sí sin servidor" es correcta tal cual está en el texto.
    -> Entonces parece que lo que yo sabía ya está desactualizado. ¡Te agradecería si me pudieras contar qué cambió desde la información que yo conocía (y compartí)!
  2. Sí hace falta un servidor TURN, pero como es una librería, dejémoslo pasar.
    -> Lo que dijo skageektp es correcto. Como es una librería, se puede dejar pasar hasta cierto punto. Yo fui demasiado sensible.

Yo
3. Para usarlo bien, STUN por sí solo no basta y hace falta TURN, así que es una exageración decirlo así~
era lo que quería expresar.
 
kimjoin2 2025-10-29

Respecto a las explicaciones de los puntos 1 y 2:

  1. Estado en el que es posible la comunicación de paquetes por UDP entre ambas partes -> Estado en el que ambos peers pueden comunicarse por paquetes UDP
  2. Estado en el que ambas partes solo conocen la dirección informada por STUN -> Estado en el que ambos peers solo conocen la dirección informada por STUN

Lo corregiré así. En la publicación original puede prestarse a malentendidos.