Start Here
Rings is a peer-to-peer network for the sovereign age. Browser tabs and native daemons join one overlay, find each other by DID, and exchange messages over direct WebRTC datachannels routed by a Chord DHT. Direct connections do not need an application server in the data path. Bootstrap and signaling establish the first links; if ICE selects a configured TURN relay, that relay carries the transport traffic.
The overlay is the communication layer: it routes by DID and, once two peers have completed the E2E handshake, encrypts to a DID. It does not hide who is talking to whom. Privacy is the job of the privacy layer, the onion loops that bound what each relay can learn to its predecessor and its successor; the contract of each layer is drawn in the security model.
On top of the overlay, Rings gives applications a namespace-scoped protocol runtime. A protocol is a pure state machine; its interpreter shell performs the side effects, and only within its own namespace. Built-in protocols cover peer service relay and echo; yours are registered under a namespace of their own.
Rings is written in Rust and compiles to native binaries and to WebAssembly, so the same node runs in a terminal, in a browser tab, and inside a host that speaks C. This book is the reference for all three; the Guide on the site is its short form.
Where Rings fits
✅ supported · ❌ not provided. Qualifications are listed below the table.
| Network | Browser P2P | Structured P2P | Privacy layer | E2E encryption |
|---|---|---|---|---|
| Rings | ✅ | ✅ Chord | ✅ Separate layer | ✅¹ |
| libp2p | ✅ | ✅ Kademlia² | ❌ | ✅³ |
| aMule / Kad | ❌ | ✅ Kademlia | ❌ | ❌⁴ |
| Nostr | ❌ | ❌ | ❌ | ✅⁵ |
| Nym mixnet | ❌ | ❌ | ✅ Full mixnet path | ✅⁶ |
| Tor | ❌ | ❌ Relay network | ✅ Onion circuits | ✅⁷ |
| I2P | ❌ | ✅ netDb² | ✅ Tunnel network | ✅⁶ |
| WebTorrent (browser) | ✅ | ❌ | ❌ | ✅³ |
Browser P2P means the browser itself connects as a peer; a browser UI or gateway client does not qualify. Structured P2P includes DHT-based discovery; it does not imply that application traffic is routed through the DHT. Privacy means network metadata protection, separate from payload encryption.
- Rings E2E streams require the E2E handshake; plain overlay messages are not E2E-encrypted.
- libp2p offers an optional Kademlia DHT. I2P uses a Kademlia-based netDb for discovery; messages travel through tunnels.
- Encrypted peer connections: libp2p includes circuit-relayed connections; browser WebTorrent uses WebRTC/DTLS. This does not make published content private or add E2E to pubsub forwarding.
- aMule protocol obfuscation is not a secure E2E guarantee. This row covers Kad; eD2k uses indexing servers.
- Nostr supports encrypted messages, such as NIP-44 payloads; public events are not encrypted.
- Between Nym clients or I2P destinations. Traffic beyond an exit/outproxy needs application encryption.
- Tor provides E2E for onion services; ordinary websites need HTTPS beyond the exit. A privacy layer is not an unconditional anonymity guarantee.
Primary sources
Sources for the comparison
- Rings: security model.
- libp2p: WebRTC, Kademlia DHT specification, encrypted circuit-relay connections.
- aMule: eD2k/Kad, browser remote control, protocol obfuscation. Obfuscation targets protocol classification rather than a secure E2E messaging contract.
- Nostr: NIP-01 client/relay protocol, NIP-44 encrypted payloads.
- Nym: mixnet design, browser SDK, client-to-client encryption.
- Tor: relay network, onion-service E2E encryption, HTTPS and exit traffic.
- I2P: Kademlia-based network database, tunnels and destination-to-destination encryption.
- WebRTC standards: ICE, RFC 8445, IP address handling, RFC 8828, data channels, RFC 8831, DCEP, RFC 8832.
- WebTorrent (browser): browser-to-browser WebRTC and tracker discovery, WebRTC data-channel encryption. The row covers browser peers, not the native client’s DHT support.
Sources checked September 22, 2026.
Choose a runtime
| Runtime | Start with |
|---|---|
| Native node | Install, then Host a Native Node and Operate a Node from the CLI |
| Browser (Wasm) node | Build for Wasm and Browser Node and Extension |
| Another language | Embed via C FFI |
| An AI coding agent | llms.txt |
If you are new to Rings, start with a native node: it is the shortest path to a running peer and to the JSON-RPC API every runtime shares.
How it works
- Architecture: the layers, from transport to application.
- How handshake works and Exchange SDP: how two peers open a datachannel.
- DHT - Network Layer: routing and lookup on the Chord ring.
- Account Abstraction: DIDs and the signature schemes behind them.
- config.yaml: every section of a native node’s configuration.
Beyond the book
- Rings whitepaper: the protocol paper.
- Security model: the assumptions, deployment models, the boundary between DID authentication and Sybil resistance, and the contracts of the communication layer and the privacy layer. Read it before deploying.
- Roadmap: where the network layer and the privacy layer are heading.
- Source on GitHub: the code, examples, and issues.
- License: AGPL-3.0-only, so a product or hosted service built on Rings publishes its source; a commercial license for use outside those terms is available on request.