Trystero - Membuat Web App Multipemain Instan Tanpa Server

• Library yang memungkinkan implementasi web app multipemain yang saling terhubung tanpa server hanya dengan beberapa baris kode
• Berbasis WebRTC di browser, memanfaatkan jaringan publik sebagai kanal pertukaran sinyal (signaling) untuk mengotomatiskan pencocokan P2P dan komunikasi
  • Pilih salah satu dari BitTorrent, Nostr, MQTT, IPFS, Supabase, Firebase untuk melakukan penemuan peer tanpa server
  • Data aplikasi setelah signaling dikirim lewat P2P + enkripsi E2E tanpa melalui perantara
• Menyediakan abstraksi tingkat tinggi seperti Rooms/broadcasting, serialisasi otomatis, chunking/throttling untuk data besar, event progres, enkripsi data sesi, metadata stream, dan lainnya
• Berjalan tidak hanya di browser tetapi juga di Node/Deno/Bun, serta mendukung fitur praktis seperti konfigurasi server TURN, hook React, dan eksekusi sisi server
• Karena memanfaatkan infrastruktur publik tanpa konfigurasi, library ini cocok untuk berbagai eksperimen dan prototyping

• Situs demo - https://oxism.com/trystero dapat langsung dicoba dengan membukanya di 2 tab sekaligus lalu menggerakkan/mengeklik mouse
• Lihat apa saja yang dibuat orang dengan Trystero - Awesome Trystero

[kimjoin2]

Server TURN disediakan leluhur Anda?

[helio]

'stun:stun.cloudflare.com:3478' tampaknya ditanam langsung di dalam source code.

[kimjoin2]

Bukan stun, tapi turn.
stun itu sekadar memberi tahu identitasmu berdasarkan stun, jadi ada beberapa server publik,
sedangkan turn harus me-relay trafik (mahal), jadi harus bayar untuk memakainya atau membangun sendiri.
Contoh) https://github.com/coturn/coturn
Kurang lebih seperti itu.

Memang sering ada kasus komunikasi bisa dilakukan hanya dengan stun,
tapi untuk bilang secara sederhana bahwa itu "berfungsi" rasanya.....
Ya...... memang bisa sih..... tapi hmm.. kurang lebih begitu rasanya.

[skageektp]

Kalau pencocokannya p2p, bukannya tidak perlu TURN?

[kimjoin2]

Sepertinya ini bergantung pada maksud dari "pencocokan p2p" yang Anda bicarakan di WebRTC.

1. kondisi ketika keduanya bisa saling berkomunikasi paket lewat UDP
2. kondisi ketika keduanya hanya mengetahui alamat yang diberitahukan oleh STUN

Kalau yang dimaksud nomor 1, seperti yang Anda katakan, tidak perlu TURN.
Bahkan pada nomor 2 juga, jika situasinya mendukung dan komunikasi UDP dua arah berhasil, maka TURN tidak diperlukan.

TURN dibutuhkan pada kondisi nomor 2 ketika komunikasi paket UDP dua arah gagal.

Faktor yang menyebabkan kegagalan antara lain

• peer berada di balik symmetric NAT sehingga alamat (atau port) yang ditemukan oleh STUN tidak bisa digunakan, atau
• ada bagian di tengah jaringan yang hanya mengizinkan trafik web (80, 443), atau
• ada bagian di tengah jaringan yang memblokir UDP, atau
• satu sisi hanya memakai IPv4 dan sisi lain hanya memakai IPv6, atau
• dan lain-lain?

Dalam kasus seperti itu, harus memakai TURN.

(Baru tahu saat memeriksa ingatan saya bahwa IPv4 only <-> IPv6 only memang tidak bisa)

[skageektp]

Ya, maksud saya nomor 2. Anda bilang 'saling terhubung tanpa server' dan 'library', tapi bukankah Anda berharap terlalu banyak...

[kimjoin2]

Bagian yang ingin Anda sampaikan itu yang mana?

1. Karena koneksi bisa dilakukan hanya dengan alamat (+port) yang diberitahukan oleh STUN, server TURN tidak diperlukan. Jadi ungkapan "saling terhubung tanpa server" memang benar secara tekstual.
   -> Kalau yang ini, mungkin pengetahuan saya sudah lama. Jika ada perubahan situasi setelah informasi yang saya tahu (dan saya bagikan), saya akan berterima kasih kalau Anda bisa memberi tahu bagian apa yang berubah~!
2. Server TURN tetap diperlukan, tetapi karena ini pustaka, ya anggap saja segitu masih bisa dimaklumi.
   -> Yang disampaikan skageektp benar. Karena ini pustaka, segitu memang masih bisa dimaklumi. Saya yang terlalu sensitif.

Saya sendiri
3. Kalau mau dipakai dengan benar, STUN saja tidak cukup dan TURN diperlukan, jadi terasa terlalu dibesar-besarkan~
sedang mencoba menyampaikan hal itu.

[kimjoin2]

Untuk penjelasan nomor 1 dan 2,

1. keadaan di mana paket dapat saling dikomunikasikan lewat UDP -> keadaan di mana antar-peer dapat saling berkomunikasi paket lewat UDP
2. keadaan di mana hanya mengetahui alamat yang diberitahukan oleh STUN -> keadaan di mana antar-peer hanya mengetahui alamat yang diberitahukan oleh STUN

akan saya koreksi menjadi seperti itu. Di tulisan asli ada ruang untuk menimbulkan salah paham.