Verify zero metadata — 1-to-1 & Whisper private chat
This page is a verification checklist for Buzzio’s claim that 1-to-1 chat and Whisper private chat are zero durable conversation-metadata surfaces.
Use it after reading the scoped definition: What zero metadata means.
Related: 1-to-1 chat · Whisper private chat · Message delivery · How to verify crypto · Privacy guarantees
What “pass” means
| Surface | Pass condition |
|---|---|
| 1-to-1 chat | After nothing remains undelivered on the relay for that conversation, Buzzio does not keep a lasting server archive of who talked to whom or what was said for that chat. Readable history is on devices (SQLCipher). |
| Whisper private chat | After the session expires (or closes) and cleanup runs, Buzzio does not keep a durable server archive of that session’s content or a lasting “these people Whisper-chatted” graph. |
Pass does not mean: Tor anonymity, “Buzzio stores nothing anywhere,” or that short-lived undelivered queues / accounts / FCM / blocks never exist.
Quick matrix
| Check | 1-to-1 | Whisper private chat |
|---|---|---|
| Content E2EE (operator cannot read bodies) | Yes | Yes |
| Durable server transcript of message bodies | No | No (after expiry) |
| Durable who↔whom conversation archive after delivery / expiry | No | No |
| Temporary operational data while delivery / session is live | Yes (queue / session plumbing) | Yes (session token, expiry, push wake) |
| Readable history location | Local device DB | Local device / session store until wiped |
A. Verify 1-to-1 chat
A1. Claim to check
Once there are no undelivered messages left on the relay for a conversation, Buzzio does not retain a server-side record of who you are talking to for that chat, and never keeps a searchable archive of what was said.
A2. Delivery path checklist (reviewer)
Walk Message delivery path and confirm each step matches shipped behavior:
| # | Step | What “good” looks like |
|---|---|---|
| 1 | Encrypt on device | Body sealed with Double Ratchet / AES-GCM before upload |
| 2 | Outer sealed envelope | Preferred path uses sealed sender (from: "sealed") — no durable plaintext sender on the outer relay record |
| 3 | Blind relay write | Undelivered ciphertext only in a short pending queue |
| 4 | FCM wake | Sealed wake omits plaintext sender_id where sealed wakes apply |
| 5 | Recipient open | Recipient opens envelope locally; learns sender from inner payload |
| 6 | Delete-on-delivery | Relay copy removed after successful receive |
| 7 | Local history | Readable transcript stored in SQLCipher on device — not a Buzzio-operated sealed cloud inbox |
Status of sealed write cutover: Privacy guarantees — sealed-program status.
A3. Retention check
| Item | Expected (Retention and limits) |
|---|---|
| Undelivered 1:1 pending purge | ~3 days safety purge if never delivered |
| After successful delivery | Pending envelope gone — no lasting who↔whom dossier for that chat |
A4. User / lab experiment (conceptual)
You do not need Buzzio admin access to understand the product shape:
- Send a sealed 1-to-1 message between two test accounts; confirm both sides can decrypt (content secrecy).
- Confirm the conversation list and transcript remain available offline on device after delivery (local-first history).
- Confirm the product does not offer a Buzzio web inbox that reloads that private transcript from a server archive (no operator-readable cloud mailbox for sealed 1:1).
- Optional privacy tools (Vanish, Secure View, disappearing timers) reduce device residue; they are orthogonal to the server zero-metadata claim — see 1-to-1 chat.
A5. Honest exceptions (still not a chat graph)
These may exist and are not a durable private chat archive:
| Exception | Why it exists |
|---|---|
| Account / Buzzio ID / keys | Identity |
| FCM tokens | Wake devices |
| Short undelivered queue | Recipient offline |
| Blocks / reports | Safety |
| Optional shared pins (short snippet) | Feature you enable |
| Cert verify at delivery CF | Abuse / rate limits — see Why delivery still learns the sender |
B. Verify Whisper private chat
B1. Claim to check
Whisper private chat is a zero-metadata conversation surface after expiry: meet → talk E2E → expire → leave no lasting sealed chat archive on Buzzio servers for that session.
Not the same as Whisper Questions (owner-readable answers — not zero-metadata).
B2. Session lifecycle checklist
| # | Step | What “good” looks like |
|---|---|---|
| 1 | Create session | Time-limited session (presets ~1h–168h); QR/link join material |
| 2 | Encrypt on device | Session keys on participant devices; ciphertext on relay paths |
| 3 | Active session plumbing | Temporary fields only (expiry, scan limits, push wake, settings flags) |
| 4 | Membership gating | Session membership / creator mapping isolated from a permanent social graph |
| 5 | Expiry / close | Server session records and relay paths deleted |
| 6 | Local wipe | Local session data removed per design |
Details: Whisper private chat.
B3. Retention check
| Item | Expected |
|---|---|
| Session lifetime | Creator-chosen preset (up to ~7 days) |
| After expiry + cleanup | No durable content archive; no lasting who↔whom Whisper graph for that token |
B4. User / lab experiment (conceptual)
- Create a Whisper private session with a short TTL between two devices.
- Exchange messages; confirm both can read (E2EE works).
- Let the session expire (or close it); confirm both sides lose the live room as designed.
- Confirm Whisper Questions is a different product path (answers stored for the link owner) — do not use it as a negative control for Whisper private chat.
B5. Honest exceptions during an **active** session
While the room is live, Buzzio may temporarily hold operational fields (token, expiry, scan count, push tokens, encrypted creator routing). That is session plumbing, deleted after expiry — not a permanent contact edge.
C. Negative control — Feature mode *should* look different
To verify the claim is scoped (not marketing blur), spot-check a shared surface:
| Surface | Expect more durable product data |
|---|---|
| Open-history groups | Shared backscroll |
| Communities | Roles, channels, moderation history |
| Broadcast | Operated feed / posts |
| Whisper Questions | Owner-readable answers |
Matrix: Sealed vs shared.
If Feature mode and sealed 1-to-1 / Whisper looked identical in retention, the privacy model would be dishonest. They are supposed to differ.
D. Crypto verification (content secrecy)
Zero metadata is about durable conversation archives. Content secrecy is verified separately:
- Follow How to verify — clone open-source crypto, run tests.
- Read Sealed sender for envelope shape.
- Confirm sealed 1:1 claims align with Privacy guarantees.
E. Pass / fail summary
| Question | Expected answer for 1-to-1 + Whisper private |
|---|---|
| Can Buzzio staff open message bodies? | No (E2EE; keys on devices) |
| After delivery / expiry, is there a durable server dossier of who privately talked to whom for that chat? | No |
| After delivery / expiry, is there a searchable server archive of what they said? | No |
| Do accounts, FCM, short queues, or safety tools still exist? | Yes — operational, not a sealed chat graph |
| Does Feature mode store more? | Yes — by design |