🔒 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 (it's hosted on IPFS — there is no git server here, or any server at all):

git clone https://git-chat.ardegazu.ro/sueta.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 a one-way room id (rendezvous only) and per-sender AES-256-GCM keys.
• The relay is blind. Peers meet through a ~500-line WebSocket relay that forwards opaque encrypted blobs. It cannot read offers, names, or messages — verified by tests that grep every frame for plaintext.
• Everything else is browser ⇄ browser. WebRTC datachannels (DTLS + app-layer AES-GCM), full mesh up to ~12 peers, STUN/TURN for NAT traversal with ephemeral HMAC credentials.
• History lives in the members. Devices persist their rooms locally (IndexedDB) and replay history to newcomers over the encrypted channels. 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 pinned to IPFS, served through an HTTPS tunnel that is deliberately never connected — its "offline page" is the site. This page you're reading works the same way.

Run it yourself

# dev: relay + app
cd server && go run . --dev          # :8080
cd client && npm install && npm run dev   # :5173, proxies /ws to :8080

# tests (real Chromium — WebRTC needs real UDP)
cd server && go test ./...
cd client && node e2e/mesh.e2e.mjs

To deploy your own: any Debian box runs coturn + the Go relay (deploy/ has the config, systemd unit and a one-command deploy script); host the client build anywhere static — IPFS, a CDN, a folder behind nginx. Full steps in docs/SIGNAL-SERVER.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 your relay — or reuse an existing one; the relay never learns what app it's carrying,
• define your own payloads and broadcast them — they're sealed per-sender automatically.

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, opaque room ids, ciphertext sizes and timing. Not content, not names, not who-is-who inside a room.
• 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.