Encrypted-content share links

Cordy commented

2026-07-25 16:25:43 +00:00

Owner

Public share links (/s/<token>) currently assume plaintext-readable content. When the backing object is age-encrypted, the share handler must decrypt on serve (server-side, using the owner's or a share-scoped key).

Decide key scope for shares of encrypted files (owner identity vs dedicated share recipient).
Preserve Range + password/expiry semantics.

Deferred from the v0.3 encryption probe.

Public share links (`/s/<token>`) currently assume plaintext-readable content. When the backing object is age-encrypted, the share handler must decrypt on serve (server-side, using the owner's or a share-scoped key). - Decide key scope for shares of encrypted files (owner identity vs dedicated share recipient). - Preserve Range + password/expiry semantics. Deferred from the v0.3 encryption probe.

Cordy added this to the v0.4 — Real competitor (parity + hardening) milestone

2026-07-25 16:25:43 +00:00

Cordy commented

2026-08-03 19:02:49 +00:00

Author

Owner

Decision — deferred (Manuel's review, relayed by Nikola 2026-07-31):

"Not yet set/decided on how we want to share files."

Stays open but re-gated: the blocker is no longer the encryption review, it's a product decision on the sharing model itself. Until how-we-share is settled, encrypted-content share links have no target to build against. Current shipped behaviour stands documented (main.go note): with per-user custody there is no user context on public /s/, so shares of encrypted content cannot decrypt.

**Decision — deferred (Manuel's review, relayed by Nikola 2026-07-31):** > "Not yet set/decided on how we want to share files." Stays open but re-gated: the blocker is no longer the encryption review, it's a **product decision on the sharing model itself**. Until how-we-share is settled, encrypted-content share links have no target to build against. Current shipped behaviour stands documented (main.go note): with per-user custody there is no user context on public `/s/`, so shares of encrypted content cannot decrypt.

Cordy commented

2026-08-04 19:47:51 +00:00

Author

Owner

Design decided (Nikola, 2026-08-04) — this unblocks #19. Sharing splits into two lanes: peering (recipient has a Cairn instance — v0.5 track, delivery re-encrypts to the recipient's own key, #104) and links (recipient has NO instance — this issue). What follows is the links design.

The claim (marketing-honest, agreed): the public share surface stores and serves only ciphertext; compromising the storage backend, the share database, or sniffing the download yields nothing without the key material in your hand. Explicitly NOT "zero-knowledge": a compromised cairnd sees content (it always does — transparent server-side decryption is the product), and the decryption JS is served by the instance itself. We say so in the docs.

Mechanism — on-the-fly age re-encryption (no stored copy): at download, the server decrypts the object internally (owner/space key, exactly like any read) and re-encrypts the stream to a share-specific age recipient. Nothing extra is stored, revocation stays instant (the mint happens per fetch), and the crypto cost rides the existing scaling answer — the --target=crypto role (#33), per Manuel's compute-scaling design. Concurrency-capped like everything else.

Two modes:

Fragment mode: an ephemeral age X25519 identity is generated at share creation; the private half goes into the URL #fragment (never sent to the server, server keeps only the public recipient). One self-sufficient artifact — convenience default.
Password mode: the payload is encrypted to an age scrypt (passphrase) recipient. Two artifacts (link + password via any out-of-band channel). Note: age does not allow mixing scrypt with other recipient types in one file, so the modes are alternatives per link, not additive.
Server-side gate stays in password mode: we keep a download gate with a stored verifier derived separately from the content key (verifier and key from independent salts, so the verifier reveals nothing). Without it, anyone holding the bare link could pull ciphertext and brute-force the passphrase offline; with it, fetch itself requires the password and rate limiting still bites.

Recipient experience: link opens a lightweight viewer page served by the instance; decryption happens in-browser via typage (Filippo's official TypeScript age — the one new UI dependency). v1 caps link-share file size (browser-memory decrypt); streaming decrypt for very large files is a later lift.

This REPLACES the existing plain /s/ share links — not a parallel feature. The new pipeline works uniformly on encrypted AND unencrypted instances (on unencrypted ones the "internal decrypt" is a plain read; the share surface still serves only ciphertext). Everything the current shares have carries over: expiry, revocation, admin list/revoke-all, and the org policy panel applies unchanged and instance-wide — shareMaxExpiry (enforced ceiling), shareRequirePassword (forces password mode, fragment mode refused), shareUploadsForbidden. Upload-drop links survive too and get stronger on encrypted instances: anonymous uploads are encrypted to the owner's public recipient + recovery — no secrets involved, the public surface never holds plaintext at rest.

Known and accepted: a recipient who has downloaded ciphertext and holds the key keeps that file forever — revocation stops future fetches, nothing un-rings the bell (true of every sharing system; documented). Wrong password in password mode fails at the gate (server) — the in-browser decrypt failure path exists only if someone bypasses the viewer.

age-CLI compatibility (payload is a genuine age file, so curl | age -d would work): deliberately NOT surfaced or documented as a feature — a very small user subset would care. Filed for market review in v0.6 (#113).

Build split:

Server: share-mint pipeline (ephemeral/scrypt recipients, on-the-fly re-encrypt through the crypto role, password verifier gate, policy enforcement, replace the /s/ payload path).
Web: share-dialog changes (mode selection under policy) + recipient viewer page with typage.
Docs: handbook page + the claim-boundary text.

**Design decided (Nikola, 2026-08-04) — this unblocks #19.** Sharing splits into two lanes: **peering** (recipient has a Cairn instance — v0.5 track, delivery re-encrypts to the recipient's own key, #104) and **links** (recipient has NO instance — this issue). What follows is the links design. ## Strong shares: ciphertext-only share links **The claim (marketing-honest, agreed):** *the public share surface stores and serves only ciphertext; compromising the storage backend, the share database, or sniffing the download yields nothing without the key material in your hand.* Explicitly NOT "zero-knowledge": a compromised cairnd sees content (it always does — transparent server-side decryption is the product), and the decryption JS is served by the instance itself. We say so in the docs. **Mechanism — on-the-fly age re-encryption (no stored copy):** at download, the server decrypts the object internally (owner/space key, exactly like any read) and re-encrypts the stream to a **share-specific age recipient**. Nothing extra is stored, revocation stays instant (the mint happens per fetch), and the crypto cost rides the existing scaling answer — the `--target=crypto` role (#33), per Manuel's compute-scaling design. Concurrency-capped like everything else. **Two modes:** - **Fragment mode:** an ephemeral age X25519 identity is generated at share creation; the private half goes into the URL `#fragment` (never sent to the server, server keeps only the public recipient). One self-sufficient artifact — convenience default. - **Password mode:** the payload is encrypted to an age **scrypt (passphrase) recipient**. Two artifacts (link + password via any out-of-band channel). Note: age does not allow mixing scrypt with other recipient types in one file, so the modes are alternatives per link, not additive. - **Server-side gate stays in password mode:** we keep a download gate with a stored *verifier* derived separately from the content key (verifier and key from independent salts, so the verifier reveals nothing). Without it, anyone holding the bare link could pull ciphertext and brute-force the passphrase offline; with it, fetch itself requires the password and rate limiting still bites. **Recipient experience:** link opens a lightweight viewer page served by the instance; decryption happens in-browser via `typage` (Filippo's official TypeScript age — the one new UI dependency). v1 caps link-share file size (browser-memory decrypt); streaming decrypt for very large files is a later lift. **This REPLACES the existing plain `/s/` share links** — not a parallel feature. The new pipeline works uniformly on encrypted AND unencrypted instances (on unencrypted ones the "internal decrypt" is a plain read; the share surface still serves only ciphertext). Everything the current shares have carries over: expiry, revocation, admin list/revoke-all, and the **org policy panel applies unchanged and instance-wide** — `shareMaxExpiry` (enforced ceiling), `shareRequirePassword` (forces password mode, fragment mode refused), `shareUploadsForbidden`. Upload-drop links survive too and get *stronger* on encrypted instances: anonymous uploads are encrypted to the owner's public recipient + recovery — no secrets involved, the public surface never holds plaintext at rest. **Known and accepted:** a recipient who has downloaded ciphertext and holds the key keeps that file forever — revocation stops future fetches, nothing un-rings the bell (true of every sharing system; documented). Wrong password in password mode fails at the gate (server) — the in-browser decrypt failure path exists only if someone bypasses the viewer. **age-CLI compatibility** (payload is a genuine age file, so `curl | age -d` would work): deliberately NOT surfaced or documented as a feature — a very small user subset would care. Filed for market review in v0.6 (#113). **Build split:** 1. Server: share-mint pipeline (ephemeral/scrypt recipients, on-the-fly re-encrypt through the crypto role, password verifier gate, policy enforcement, replace the `/s/` payload path). 2. Web: share-dialog changes (mode selection under policy) + recipient viewer page with typage. 3. Docs: handbook page + the claim-boundary text.

Rows
Columns

Encrypted-content share links #19

Strong shares: ciphertext-only share links