Trystero - crie webapps multiplayer instantâneos sem servidor

• Uma biblioteca que permite implementar webapps multiplayer que se conectam entre si sem servidor com apenas algumas linhas de código
• Baseada em WebRTC no navegador, usa redes públicas como canal de troca de sinalização (signaling) para automatizar o pareamento P2P e a comunicação
  • Escolha entre BitTorrent, Nostr, MQTT, IPFS, Supabase, Firebase para fazer descoberta de pares sem servidor
  • Depois da sinalização, os dados do app são transmitidos diretamente via P2P + criptografia E2E, sem passar por intermediários
• Oferece abstrações de alto nível como rooms/broadcasting, serialização automática, chunking/throttling de grandes volumes de dados, eventos de progresso, criptografia de dados de sessão e metadados de stream
• Funciona não só no navegador, mas também em Node/Deno/Bun, com suporte a recursos práticos como configuração de servidor TURN, hooks para React e execução no lado do servidor
• Por aproveitar infraestrutura pública sem configuração, é ótimo para vários tipos de experimentos e prototipagem

• Site de demonstração - https://oxism.com/trystero — abra em duas abas ao mesmo tempo e mova/clique o mouse para ver funcionando na hora
• Veja o que as pessoas estão criando com Trystero - Awesome Trystero

[kimjoin2]

O servidor TURN é fornecido pelos seus ancestrais?

[helio]

Parece que 'stun:stun.cloudflare.com:3478' está fixado no código-fonte.

[kimjoin2]

É TURN, não STUN.
O STUN, de forma simples, só serve para dizer quem você é com base no STUN, então existem alguns servidores públicos.
Já o TURN precisa retransmitir o tráfego, então (como é caro) você tem que pagar para usar ou então montar a sua própria infraestrutura.
Ex.) https://github.com/coturn/coturn
É esse tipo de coisa.

Muitas vezes dá para se comunicar só com STUN, mas dizer simplesmente que “funciona” é meio...
Funcionar, funciona... mas... hmm... essa é a sensação.

[skageektp]

Se é pareamento p2p, não precisa de TURN, certo?

[kimjoin2]

Acho que depende do que você quer dizer com "matching P2P" no WebRTC.

1. Um estado em que ambos conseguem trocar pacotes via UDP
2. Um estado em que ambos só conhecem o endereço informado pelo STUN

No caso 1, como você disse, não precisa de TURN.
No caso 2, se a situação for favorável e a comunicação UDP entre os dois tiver sido bem-sucedida, também não precisa de TURN.

No caso 2, quando a comunicação de pacotes via UDP entre os dois falha, aí é necessário TURN.

Os motivos para falhar incluem:

• o peer estar atrás de um symmetric NAT, por exemplo, e não dar para usar o endereço (ou a porta) descoberto pelo STUN
• em algum ponto da rede, só ser permitido tráfego web (80, 443)
• em algum ponto da rede, o UDP estar bloqueado
• um lado usar apenas IPv4 e o outro apenas IPv6
• etc.?

Nesses casos, é preciso usar TURN.

(Eu só fui descobrir agora, enquanto conferia isso de memória, que IPv4 only <-> IPv6 only não funciona.)

[skageektp]

Sim, então é a opção 2. Vocês disseram "interligação mútua sem servidor" e "biblioteca", mas talvez estejam esperando coisa demais...

[kimjoin2]

A que parte exatamente você quer se referir?

1. Como é possível fazer a conexão apenas com o endereço (+porta) informado pelo STUN, não é necessário um servidor TURN. Portanto, a expressão "conectar entre si sem servidor" está literalmente correta no texto.
   -> Se for isso, então acho que o que eu sei já está desatualizado. Agradeceria se você pudesse me informar o que mudou desde o que eu conhecia (e compartilhei) até agora~!
2. O servidor TURN é necessário, mas como é uma biblioteca, dá para relevar esse nível de detalhe.
   -> O que o skageektp disse está certo. Como é uma biblioteca, talvez dê para relevar esse tanto. Eu que fui sensível demais.

Eu estava
3. para usar de forma adequada, só STUN não basta e TURN é necessário, então isso é um exagero grande~
querendo expressar isso.

[kimjoin2]

Vou corrigir as explicações 1 e 2.

1. Estado em que é possível comunicar pacotes por UDP mutuamente -> Estado em que os pares conseguem comunicar pacotes por UDP mutuamente
2. Estado em que ambos conhecem apenas o endereço informado pelo STUN -> Estado em que os pares conhecem apenas o endereço informado pelo STUN

Vou corrigir assim. No texto original, isso pode causar mal-entendido.