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 · zero durable chat metadata 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 · zero durable chat metadata 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 | Yes — plaintext on Buzzio servers | TLS in transit; durable history for members (~365 days default class) |
| Communities | Shared | Yes — plaintext on Buzzio servers | TLS in transit; roles, channels, moderation, backscroll |
| Broadcast channels | Shared | Yes — plaintext posts on Buzzio servers | TLS in transit; 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 |
| Service / worker bots | Shared (by design) | Yes — Buzzio + bot developer server | Short Buzzio text retention (~7 days); not sealed |
| Contact sync | Opt-in ops | Contact ID map (not chat bodies) | Off by default |
| Encrypted backup | Opt-in | Client-encrypted blobs; unlock needs a seed-derived account key or separate recovery key | Off unless enabled |
| Private Vault | Opt-in storage | Client-encrypted files and metadata; dedicated seed-derived key or separate Vault recovery key | Off unless enabled |
| Note to Self | Device-first | Encrypted notes; no durable cloud vault; ≤3-day mailbox ciphertext | Local + linked-web notes key |
| Saved Messages | Opt-in Premium store | Durable ciphertext; operators see store metadata, not bodies | Stable SMRK; 200 MB media pool |
| Stickers (import) | Device library | Pack files stay local after import | Sending follows the chat surface’s mode |
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:
- Plaintext message text on Buzzio servers (so history, mentions, search, moderation, and bots work), and/or
- Durable history for late joiners, discovery, roles, moderation, owner-readable submissions, or developer webhooks (bot DMs / worker events)
Shared mode is still:
- Encrypted in transit (TLS)
- Not end-to-end encrypted — Buzzio can read Community / OHG / Broadcast text
- Media on those surfaces is stored as CDN bytes with signed access (already not E2E)
- 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
1-to-1 chat and Whisper private chat are the primary zero-metadata surfaces. 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.
Hands-on checklist: Verify zero metadata (1-to-1 & Whisper)