chr15m / webrtc-signaling-mesh

Decentralized signaling for WebRTC
23 stars 1 forks source link

🚧 Under construction. Please check back later.

Quickstart: run a node

Web browsers can send messages directly peer-to-peer using WebRTC. This gives us a way to build decentralized web applications where browsers (peers) can communicate directly without a trusted third-party server in between. Unfortunately the WebRTC connection phase requires centralized services for establishing the route between peers, NAT hole-punching, and negotiating the connection. These centralized must provide a signalling protocol, STUN, and sometimes TURN connectivity, which makes them a single point of failure in peer-to-peer web applications.

This server provides a solution to this problem. It uses the bittorrent DHT to find other server nodes and then forms a mesh that client browsers can use to coordinate WebRTC connectivity in a decentralized, trust-minimised way. It additionally provides a STUN and TURN service that clients can also use.

Server nodes are protected from becoming overloaded by a proof-of-work requirement on clients. As load increases on a server the proof-of-work they require from clients increases, and clients can use this signal to select for nodes which are under less load, thereby ensuring better service and distribution of traffic over the network.

Run a node

...

API

If content-type is set to json then JSON data will be returned, otherwise an HTML summary will be returned.

Post size is limited to 1k, and every post requires PoW.

PoW is proportional to max(cpu, mem). Additional PoW is required for every message sent in the past minute to the /room/HASH endpoint.

A STUN & TURN server are also run. Authentication tokens for the STUN/TURN server can be obtained from the /token endpoint.

PoW tokens are generated against a time-stamped HMAC of the server secret which the server can use to establish recency.