Files only you can open.

The full round-trip

1. Setup. You enter an email and create a passkey. Your browser derives your identity keypair from it (PRF → HKDF → P-256), seals your email to the server's public key with HPKE, and registers {sealed_email, share_key, label} with the worker. Your private key is never sent.
2. Confirm. The worker unseals your email, holds the unsigned link in KV for an hour, and emails you a one-time confirmation link. You click it; the worker signs the link with ECDSA P-256 and hands back your permanent share link.
3. Share. You post the link anywhere. It carries your public key, your sealed email, and the server's signature. There is no secret inside it, so it is safe to make public.
4. Send. A sender opens your link and drops a file. Their browser mints a throwaway identity, runs HPKE Auth to your public key, and AES-256-GCM-encrypts the file and its metadata in 64 KiB authenticated chunks. Encryption completes before any upload starts.
5. Upload. The worker verifies your link's signature and returns a presigned R2 URL (several, for multipart on large files). The sender's browser PUTs the ciphertext straight to R2 through it; the worker only signs URLs and verifies links, never handling the bytes. A Durable Object enforces exactly-once delivery.
6. Notify. The worker unseals your email from the link, in memory only, sends you a delivery link to /d/<id>, then forgets the address. The link and the stored ciphertext both expire in 7 days.
7. Receive. You open the delivery link. Your browser re-derives your identity from your passkey, fetches the ciphertext, and runs HPKE SetupAuthR + AES-256-GCM to verify and decrypt each chunk straight to disk. Only your passkey can complete this step.
8. Clean up. The R2 object auto-deletes on its 7-day lifecycle. You can disable the link at any time; the worker flags it in KV and refuses further uploads.

Identity

Your keys are derived deterministically from your passkey, on your device, through the WebAuthn PRF extension. None of it ever reaches our servers; your passkey itself syncs only through your platform's encrypted keychain, never through us.

The keypair is bound to the canonical RP-ID, so each identity is scoped to its namespace. The private key is reproduced from the passkey secret each session and never persisted to disk.

Cipher suite

Every file uses the same fixed cipher suite, so there's no algorithm negotiation and nothing to downgrade. It's HPKE Auth mode over DHKEM(P-256, HKDF-SHA-256), with HKDF-SHA-256 and AES-256-GCM, per RFC 9180. The implementation uses @hpke/core and @noble/curves (the latter for a Safari-compatible DeriveKeyPair), verified byte-for-byte against the spec's known-answer vectors.

File format

The filename, MIME type, and exact size live in enc_metadata, sealed with AES-256-GCM under a separate key exported from the same HPKE context. Nothing about the file travels in the clear, and every chunk is authenticated, so any tampering is caught on open.

Senders are anonymous, by construction

A sender has no passkey and no account. Their browser mints a throwaway identity for each file, deriveIdentityFromPrf(random(32)), and uses it as the HPKE Auth sender. The sender_pk embedded in the file is random noise that links to nothing and no one. We never learn who sent you a thing.

The relay

• Links are signed by the server with ECDSA P-256. The worker verifies the signature before accepting an upload, and rejects revoked or expired links.
• Your email is HPKE-sealed to the server's public key inside the link, and unsealed only in memory, at confirm time and on each delivery. It is never written to storage.
• Ciphertext is PUT to Cloudflare R2 through a presigned URL and auto-deleted on a 7-day lifecycle. A SQLite-backed Durable Object enforces exactly-once delivery.
• Revocation and abuse limits live in short-lived KV: a revoke-token map, plus per-IP and per-email-hash counters. No file bytes, names, or plaintext emails are ever stored.

Threat model and non-goals

• No forward secrecy. Your identity key is long-lived, so a compromised passkey can decrypt past and future files sent to that link.
• Not post-quantum. Sharing rides on HPKE over P-256. The separate self-encryption suite (0x02) is symmetric-only and quantum-safe; sharing is not.
• Deniable by design. We make no non-repudiation claim. A recipient can forge a file attributing any sender, and senders are ephemeral regardless, so nothing here proves who sent what.
• Observable metadata. The relay can see a ciphertext's length, its timing, and IP addresses. Length implies an approximate plaintext size.
• No escrow, no rotation. We hold zero key material. Key rotation is not in v1; you would issue a fresh link instead.

Verify it yourself

The exact byte format of an encrypted file is written down in a versioned spec, with test vectors so anyone can confirm their own implementation produces identical bytes. The browser client and the worker are open source, so you can check every claim here for yourself.