☁️ WEB25.cloud

🪪 Identity: one local key, three addresses

The identity model is local-first and is inspired by mylofi/local-data-lock: key material stays in-browser and WebAuthn passkeys gate unlock/signing sessions. A single secp256k1 key backs all three identities shown on the Account page — there is no second seed and no second private key.

The passkey does more than gate the unlock — it is what the key is wrapped with. Web25 requires the WebAuthn PRF extension, and the secret the authenticator returns during a user-verified assertion is stretched through HKDF-SHA256 into a non-extractable AES-GCM key that wraps the vault. That secret never leaves the call stack and is never written to storage, so nothing persisted on the device is enough on its own to derive the wallet. A browser or security key without PRF is refused rather than quietly handed a weaker path.

The Account page shows all three side by side, each with its own copy button. The Nostr address can be added or removed there: removing it takes you off the relays and hides the address, and adding it back restores the same npub — because it was never a separate key to begin with.

📦 Publishing: Bundle pipeline + .torrentchain

Static-site deploys run through a bundle pipeline (default: gzip), then attach a signed .torrentchain manifest carrying publisher identity and integrity metadata.

💬 Direct Messenger: search an address, start a chat

Messaging UX started from michal-wrzosek/p2p-chat and replaced its manual offer/answer step entirely. You enter someone's Nostr address, and the encrypted WebRTC invitation is delivered for you through public Nostr relays — no magnet links or key pasting.

WebRTC stays the preferred transport. If a direct connection cannot be established, messages fall back to the relays — still signed and ECIES-encrypted exactly as before, with NIP-44 on top. The chat header says which path is in use: Connected · WebRTC or Connected · Nostr — one indicator, green either way.

🤝 Cryptographic validity is not consent

Verifying an invitation proves the sender is who they claim. It does not mean you want to talk to them — and anyone who knows your npub can produce a perfectly valid offer. Answering one is not free: it reveals your full ECIES public key, your EVM address, and, through ICE gathering, your machine's network addresses.

So an invitation from anyone who is not already a trusted contact simply waits. No answer is created, no ICE is gathered, and nothing is sent back until you press Accept. Declining discards it silently — the sender is not told, because telling them would confirm the address is live — and their retries are dropped, so a refusal cannot be worn down by repetition.

Trust is authorization layered on top of authentication — it replaces none of the existing checks. A trusted friend's invitation is still verified end to end, and its identity tuple (Nostr key, ECIES key, EVM address) must both validate and match what was stored, so taking over an npub does not inherit the trust attached to it. Removing a contact is a local change only: they become unknown again, and no key is deleted or rotated on either side.

🛰️ Nostr relay: browser to relay, directly

The app talks straight to one public relay over a WebSocket. There is no Web25 relay, no proxy and no signalling server — just a rendezvous both sides agree on.

Two browsers can only meet on a relay they both use. Spreading over several relays looks sturdier and behaves worse: a message accepted by one relay and a subscription healthy on another never meet, and the invitation is lost while every relay involved reports success. One relay makes finding each other predictable, at an honest cost: while that relay is down, the messenger is down with it.

🛡️ Security profile

WEB25.cloud validates signed publisher metadata and sanitizes rendered HTML with DOMPurify at load time. The sanitizer is intentionally configured in a compatibility-oriented profile (more permissive than strict defaults) to support richer static websites.