Why delivery still learns the sender

Buzzio’s sealed path hides the sender from the outer relay envelope. Delivery is still certificate-gated: the Cloud Function that writes the sealed node may learn the sender when verifying a short-lived sender certificate.

That is an intentional product limit, not an unfinished sealed-sender bug. This page explains what unidentified delivery would mean, why we do not use it for default sealed chat today, and what users still get.

Related: Sealed sender · Threat model · Privacy guarantees

Two different privacy goals

Goal	Question	Buzzio sealed default
Envelope secrecy	Does the durable undelivered node need plaintext `from: A`?	No — preferred path uses `from: "sealed"`; only the recipient opens the outer layer
Delivery-time operator blindness	Can staff / delivery CF learn that A contacted R at the moment of deliver?	Not claimed — cert verification can reveal the sender to the delivery function

Many readers conflate these. Sealed sender addresses the first. Unidentified delivery would target the second.

What “unidentified delivery” means

In an unidentified design, anyone (or any authenticated device) could drop a sealed blob addressed to recipient R without proving “I am Ghost A” to the delivery service.

Roughly:

Sender seals the message to R’s identity key (as today).
Upload is “deliver this sealed package for R” — no sender certificate check at deliver.
The delivery service only learns that R received a sealed package.
R opens the envelope locally and learns A.

Privacy gain: Cloud Functions / operator logs at deliver time would not learn A→R by Ghost ID.

Cost: The server can no longer enforce per-sender rules at the gate (block, freemium send caps, sender-keyed abuse signals) unless you invent weaker or blind substitutes (IP / App Check / payment / per-recipient flood caps only).

Why Buzzio does not use it for default sealed chat (now)

Default sealed 1:1 (and sealed controls / call invites) keep certificate-gated delivery so the product can still:

Feature	Why the delivery function needs a verified sender
Block	Reject delivery when R has blocked A — before the sealed blob sits in R’s queue and before an FCM wake
Rate limits / freemium	Count sends per Buzzio identity (e.g. free daily message caps)
Abuse controls	Apply sender-keyed limits and suspicious-pattern checks without waiting for R to open spam

With unidentified delivery, block would become mostly client-side: the sealed message might still be written and woken; R’s app would open it, see A, and discard. That is weaker protection (battery, notification noise, queue abuse) and weaker server-side safety.

Buzzio’s current choice:

Prefer server-enforced block and fair-use limits on the default sealed path, while still hiding plaintext sender on the undelivered envelope.

That matches how many sealed-sender systems keep some authenticated delivery step for abuse resistance — envelope secrecy without pretending the delivery worker is identity-blind.

What users still get today

Even with cert-gated delivery:

Content on sealed surfaces is end-to-end encrypted — staff should not read bodies.
Undelivered RTDB nodes prefer from: "sealed" — not a plaintext social graph field.
FCM wakes omit sender_id on the sealed path.
After delivery, sealed relay copies are removed (delete-on-delivery); no durable sealed cloud inbox by default.
Phone-free identity — account root is Buzzio ID + mnemonic, not a SIM number.

What we do not claim: absolute delivery-time blindness for Cloud Functions, or Tor-grade network anonymity. See Privacy guarantees and Zero metadata (scoped).

Could unidentified delivery ship later?

Possibly as an optional mode (for example a future “secret” lane), not as a silent change to default chat — and only with a redesigned abuse model.

Until then, default sealed messaging stays certificate-gated so block and related gates remain real server-side controls.

We will not market “operator never learns who messaged whom at deliver time” while this design is in place.