Just to make sure it's clear, this is not a fully in-browser solution; unfortunately an external STUN server is still required. Would be great if the browser gave us a way to discover peers fully in-browser, even just on a local network
> unfortunately an external STUN server is still required.
STUN is only required for NAT traversal. Clients can generate SDP offers without STUN, TURN, and ICE, i.e. offline; but an offer is still useless without some means of signaling.
> Would be great if the browser gave us a way to discover peers fully in-browser
WebRTC never specified signaling so this is a tough challenge. Just my two cents, a first-class SIP API would go a long way towards normalizing signaling.
Do I understand correctly that this is normal webRTC with a custom signaling server using private/public key cryptography, and STUN and TURN servers I can use?
Looks like this depends on a signaling server. I find trystero's approach interesting, where it focuses on using decentralized relays like nostr and BitTorrent for signaling: https://github.com/dmotz/trystero
Interesting project. I like the idea of letting peers act as servers, even in the browser.
We're working on a related idea with DHttp (https://dhttp.net/), but taking the QUIC/HTTP3 route. Our focus is on making ordinary devices addressable as HTTP endpoints, so existing services can be reached through stable URLs across networks, with access controlled by identity and API path.
It's interesting to see different approaches to making devices more than just clients.
Its basically the same though. You stop at the relay, then connect to a peer to find other peers. Rther than the relay handing oht p2p, the relay just hands out peer-as-server.
So, sure, we are stiill straining for decentralization.
STUN is only required for NAT traversal. Clients can generate SDP offers without STUN, TURN, and ICE, i.e. offline; but an offer is still useless without some means of signaling.
> Would be great if the browser gave us a way to discover peers fully in-browser
WebRTC never specified signaling so this is a tough challenge. Just my two cents, a first-class SIP API would go a long way towards normalizing signaling.
https://github.com/LuKks/like-webrtc/blob/a1a2ac0a90eae7319e...
- P2P servers. Listen for peer connections anywhere, even in the browser.
- Direct connections. Connect to peers across devices and networks.
- Built-in signaling. Automatic SDP/ICE exchange and negotiation.
- Identities. Shareable cryptographic addresses instead of IP addresses.
- Peer discovery. Announce and find peers using shared topics.
- WebRTC API. Use data channels, audio/video tracks and transceivers.
- Ready to use. Signaling, STUN and TURN configured by default.
We're working on a related idea with DHttp (https://dhttp.net/), but taking the QUIC/HTTP3 route. Our focus is on making ordinary devices addressable as HTTP endpoints, so existing services can be reached through stable URLs across networks, with access controlled by identity and API path.
It's interesting to see different approaches to making devices more than just clients.
It does look kinda neat, though!
So, sure, we are stiill straining for decentralization.