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.

Great work! Does this offer something beyond what https://trystero.dev/ provides?

My question as well

til: Trystero does Node, Deno, Bun now.

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?

That's always what these things are since p2p WebRTC doesn't exist.

Sure, but once a peer is attached, the goal isto match onthe p2p mesh, but the entry is always relau first

There are applications with the same mechanism: https://github.com/molvqingtai/WebChat

I just found cloudflare conveniently has some free tier TURN and STUN server allowance.

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

Single signaling server:

    wss://party.leet.ar:41337

What happens to anybody who builds on this when you turn off your server in a few months time?

This is the example. When building out yours, you can configure your ports

https://github.com/LuKks/like-webrtc/blob/a1a2ac0a90eae7319e...

Works across browsers, Node.js, and React Native.

- 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.

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.

It doesn't have built-in signaling and peer discovery, because that's impossible.

It does look kinda neat, though!

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.

At first glance, it seems extremely similar to PeerJS.