Sealed vs shared privacy model
Buzzio documents two product modes — also called the Privacy section (sealed) and Feature mode (shared) — so users and developers never confuse “encrypted in transit/storage” with “operator cannot read content.”
Privacy section (sealed): 1-to-1 chat, E2E groups, Whisper private chat, private calls.
Feature mode (shared): open-history groups, Communities, Broadcast (plus Stories / Whisper Questions where noted).
Reviewer one-pager (PDF + diagrams): Protocol one-pager · Download PDF
Quick matrix
| Feature | Mode | Can Buzzio read content as part of the product? | Durable who↔whom / history model |
|---|---|---|---|
| 1-to-1 chat | Sealed | No | E2EE · delete after delivery · local SQLCipher history |
| Private calls | Sealed | No call recordings | Encrypted signaling · P2P media when possible · local call list |
| Whisper private chat | Sealed | No | E2E session · deleted after expiry |
| E2E groups | Sealed | No readable transcript | Sender-key E2EE · short catch-up relay (~2 days) · no full open archive for late joiners |
| Open-history groups | Shared | Server-held DEK for text; media planned as CDN bytes + signed URLs (dedup) | Durable history for members (~365 days default class) |
| Communities | Shared | Server-held DEK for text; media planned as CDN bytes + signed URLs (dedup) | Roles, channels, moderation, backscroll |
| Broadcast channels | Shared | Server-managed text; media planned as CDN bytes + signed URLs (dedup) | Posts ~30 days · discovery optional |
| Stories | Shared-leaning | Media sealed for delivery; audience/views need product data | ~24 hours |
| Whisper Questions | Shared (by design) | Yes — link owner must read answers | Stored for owner; not Whisper private chat |
| Contact sync | Opt-in ops | Contact ID map (not chat bodies) | Off by default |
| Encrypted backup | Opt-in | Encrypted blobs; unlock needs user recovery key | Off unless enabled |
Sealed mode — definition
A surface is sealed when:
- Message or media content keys are held only by participant devices (or session participants).
- Servers relay ciphertext (and minimal routing metadata).
- Durable readable archives are not kept as a Buzzio-operated transcript.
- After delivery or session expiry, Buzzio aims not to retain a durable private social graph for that conversation on the sealed path.
Sealed does not mean:
- No Firebase account row
- No FCM token
- No temporary undelivered queue
- No block/report safety records
- Network observers cannot see that the app connected
Shared mode — definition
A surface is shared when the product requires:
- Server-held or server-managed encryption keys (DEK/KEK patterns), and/or
- Durable history for late joiners, discovery, roles, moderation, or owner-readable submissions
Shared mode is still:
- Encrypted in transit; text typically at rest under service keys
- Media on Communities / Broadcast / OHG may be stored as CDN bytes with signed access and content-hash reuse (plan) — still not sold, still not sealed E2EE
- Never sold as advertising or broker data
- Documented as higher operator visibility than sealed mode
How to choose (product guidance)
Use Privacy section (sealed) when:
- Conversation secrecy from the operator matters most
- Participants are a closed set (two people, QR session, private E2E group)
- Local or short catch-up history is enough
Use Feature mode (shared) when:
- New members need backscroll
- Roles, audit logs, discovery, or one-to-many publishing are required
- The product is a room or feed, not a sealed letter
“Zero metadata” — scoped definition
On sealed 1-to-1 (after nothing remains undelivered) and Whisper private chat (after expiry), Buzzio’s claim is:
No durable server archive of who privately talked to whom and what they said for that sealed conversation.
It is not a claim of absolute zero server knowledge, Tor anonymity, or silence about account/push infrastructure.
Preferred sealed 1:1 delivery uses sealed-sender envelopes so the outer relay path does not need a plaintext sender Buzzio ID.