# Sealed Spaces

A second Space tier where **the platform never receives the room key**. Today's Spaces are already
double-blind — see [The double blind](https://docs.witbitz.chat/docs/the-double-blind.md) — but that
blindness is *behavioral*: the operator is trusted not to look at a key it does, briefly, receive. A
Sealed Space removes the key from the operator's reach entirely. The platform stores ciphertext and
holds exactly one capability — the ability to **append**, never to **read**. At-rest blindness stops
being a promise about how we behave and becomes a property of how the system is built.

This is opt-in, and a **tier** — not a replacement. It buys maximal blindness at a cost, both stated
plainly below. For the membership and key model it builds on see
[The Space link is the auth](https://docs.witbitz.chat/docs/room-link-auth.md) and
[The Verified Room](https://docs.witbitz.chat/docs/verified-rooms.md); for the verifiability it leans
on see [Verify it yourself](https://docs.witbitz.chat/docs/verify.md).

---

## 1. Why this tier exists

Today the client is thin. It sends the master key — `mk`, the secret that unlocks a room — to the
server on every turn and every poll, and the agent opens the whole sealed snapshot in place to reason
over it and to re-seal it. The server is *trusted not to look*.

That trust is real, but a single capture defeats it. A logging toggle, a compelled order, or a
compromised render reads the entire history — past **and** future — because the key arrives on a
schedule and nothing bounds one room's exposure. Sealed Spaces takes the key off that schedule. The
server never receives `mk`. There is no capture to toggle.

## 2. The design

Four changes, each assembling a primitive already in the platform.

1. **The ledger becomes an append-only log of individually sealed entries** — not one snapshot
   re-sealed on every write. This is the load-bearing move: appending no longer requires reading,
   which is exactly what today fuses "write" to "hold the key."
2. **The client decrypts locally.** It syncs sealed history once, caches it on the device, then pulls
   sealed deltas by cursor — the same poll shape as today, just opaque to the server.
3. **A session-scoped, ephemeral actor does the reasoning.** On the first turn the client seals the
   assembled context *to the actor's session public key* and hands it over; after that the actor
   receives only new messages. It never sees `mk`, holds nothing across sessions, and is evicted on
   idle — plaintext-aware for the **live session only**, never at rest, never persisted-readable.
4. **Write-back is a write-only capability.** The actor appends its reply by sealing to the Space's
   public write key (`sealTo` / `openBox` — seal to a public key, open with the matching private one).
   It can add to the ledger without being able to open it.

**The net:** the platform routes ciphertext, stores ciphertext, and can append ciphertext. It cannot
read the room.

## 3. What it protects — and what it doesn't

A security claim is only worth the threat model it names. Three columns, not two.

**Structurally protected** — the point of the tier:

- **At-rest capture.** Storage dumps, a compelled disk or database order, a logging toggle, a
  compromised render. The platform holds only ciphertext and a write-only key.
- **Blast radius.** Per-Space epoch keys — a room key you can rotate — mean one Space's compromise
  doesn't cascade, and rotation bounds it going forward.

**Not protected** — stated plainly:

- **The live session** is plaintext to the ephemeral actor while it reasons. Sealed Spaces closes the
  *at-rest* hole; it does not make the AI compute over data it cannot read. That is the next tier —
  attestation / a trusted execution environment — not this one.
- **The endpoints.** A compromised member device sees plaintext; that is true of every end-to-end
  system.
- **Metadata** — who is in a Space, when they post, how large the messages are. Sealing content
  doesn't seal traffic shape.

Naming the third column is not a weakness. It's what separates a credible claim from marketing, and it
is the honest meaning of *content-blind*: blind **at rest**, bounded **in use**.

## 4. What it costs

- **No member-absent turns.** With no client present, nothing decrypts the context to feed the actor —
  so "the agent acts while everyone's away"
  ([Delegated authority](https://docs.witbitz.chat/docs/delegated-authority.md)) doesn't exist in a
  Sealed Space. This narrows the tier's use cases; it is why Sealed is a *choice*, not the default.
- **Prompt caching, likely lost.** An ephemeral per-session actor re-receives the full context each
  session, so server-side prefix caching — keyed on a stable prefix no longer kept — probably goes
  away. **Likely the largest recurring cost; worth measuring before committing.** Within a session the
  actor stays warm; the loss is at cold session-start. A **warm-actor** variant — residency billed,
  context held longer — is the dial that trades a little blindness back for cache.
- **Cold-device sync.** A new device pulls sealed history before the first render, then caches it
  locally — a first-open cost, not a per-turn one.
- **Actor residency** is billed while a session is open; the compute isn't scale-to-zero for the
  length of a burst.
- **Forward-only revocation.** Removing a member is an epoch re-key — the mechanism
  [the Bridge](https://docs.witbitz.chat/docs/the-bridge.md) already runs: future entries seal under a
  new key the removed member never gets. It cannot un-share what they already read — inherent to
  end-to-end, and worth saying out loud.

## 5. Why you can believe "never receives the key"

The claim is only as strong as your ability to check it — and it rests on apparatus already shipped.
The client is open source and **reproducibly built**, and it runs under an **enforced egress lock**: a
Content-Security-Policy that whitelists exactly where the app may talk. So an auditor can confirm the
client transmits sealed blobs and *never* `mk` — the method is in
[Verify it yourself](https://docs.witbitz.chat/docs/verify.md). The tier's transport shape can be
bound into the signed build certificate, so "the key never leaves your devices" becomes something a
third party **verifies**, not something we ask you to trust.

That verifiability is the moat. Sealed Spaces is what it protects.

## 6. Status

- **Already in hand:** per-entry sealed append and content-blind polling (scaffolded behind a flag,
  inert until enabled); `sealTo` / `openBox` for write-only append; epoch re-key in the Bridge; the
  reproducible-build + egress-lock + certificate stack.
- **To build:** the sealed client → actor session channel (seal-to-actor-pubkey); ephemeral-actor
  lifecycle and idle eviction; cursor-based sealed-delta sync as the default read path; epoch-key
  distribution to members without the platform in the loop.
- **To measure before committing:** the real prompt-caching cost on a busy Space; whether a
  warm-actor middle tier is worth offering.

---

*Sealed Spaces is not "trust us less." It is "you don't have to." The current tier remains for the
workflows that need an always-on agent; Sealed is for the rooms where the key should never leave your
hands — and where you can prove it didn't.*