🔒 sueta

a complete, working stack for serverless p2p end-to-end-encrypted web apps — this page is also the git repo.

Clone

This site serves the repository over git's dumb-HTTP protocol as plain static files (plain files — there is no git server here, or any server at all):

git clone https://git.ardegazu.ro/chat.git
cd sueta

What you get

How it works (the short version)

• The room secret never leaves the browser. It lives in the URL fragment (#…). HKDF derives every network-visible identifier one-way — the gossip topic, the log address, all AES-256-GCM keys.
• The relay is blind — more than before. Browsers meet through a libp2p circuit relay that carries noise-encrypted handshakes only; room traffic runs member⇄member and never touches it. Verified by tests that grep every relay frame for plaintext.
• Everything else is browser ⇄ browser. Direct WebRTC (noise + app-layer AES-GCM), full mesh up to ~12 peers, STUN/TURN for NAT traversal with ephemeral HMAC credentials.
• The room IS a replicated encrypted log. Messages, threads, reactions and images are entries in an append-only OrbitDB log, sealed end-to-end before they become content-addressed blocks. Devices replicate it to each other — reopen offline and your copy is there; join late and members' devices feed you everything, images included. No server stores a byte.
• Identity without accounts. One Ed25519 seed per device (password-manager-sized), session binding signatures, emoji fingerprints, trust-on-first-use with key-change warnings.
• Hosting without an origin server. The app is a static build served as plain files — there is no backend anywhere. This page you're reading works the same way.

Run it yourself

# dev: relay + app
cd deploy/relay && npm install && npm run dev   # :9090, deterministic dev PeerId
cd client && npm install && npm run dev         # :5173

# tests (real Chromium — WebRTC needs real UDP; each spawns its own relay)
cd client && node e2e/mesh.e2e.mjs

To self-host the network side: run deploy/relay/ (a ~100-line Node script) behind any TLS proxy, plus coturn for TURN, and point the client build at them with VITE_RELAY_MULTIADDR / VITE_TURN_CREDS_URL. Any willing libp2p circuit relay works — it holds no state and learns nothing. Host the client build anywhere static — IPFS, a CDN, a folder behind nginx. Full steps in docs/RELAY.md.

Build your own p2p app on this

The chat is just one consumer of the core. A new app is ~40 lines of bootstrap:

• pick an app salt (e.g. "myapp.example.com/v1") — it namespaces your rooms so apps can share one relay without collisions,
• copy client/src/lib/ (zero app-specific code in it),
• point it at any willing libp2p relay — the relay never learns what app it's carrying,
• broadcast live payloads (sealed per-sender automatically) — and, if your app wants durable shared state, append to the room's encrypted replicated log and fold entries into your UI.

The recipe with code is in client/src/lib/README.md. Shared whiteboards, turn-based games, collaborative editors, file drops — anything that fits "small group, real-time, private" fits this stack.

Guarantees & limits, honestly

• The relay operator (or anyone on the wire) sees: connection metadata, ephemeral per-session peer ids, opaque topic strings, encrypted handshake frames. Not content, not names, not who-is-who inside a room — and, new in v2, not even the room traffic itself, which flows member⇄member. Other clients of a shared relay see your ephemeral peer id exist (unlinkable across page loads), nothing more.
• Anyone with the room link is a full member — capability model. Guard links like keys.
• Identity verification is human: compare the four emoji out-of-band, like reading safety numbers aloud. No servers means no authority that can vouch for anyone.
• Full mesh scales to ~a dozen peers; beyond that you'd want an SFU, which is no longer serverless.
• History survives as long as any member's device kept it; a room everyone truly abandons is forgotten. That's the design, not a bug.