Whisper
Whisper is Buzzio’s time-limited, QR-started anonymous chat mode — built for moments when you want a sealed conversation without adding someone as a permanent contact, and without leaving a lasting “who talked to whom” archive on our servers.
In plain terms:
- You create a Whisper session and share a QR code or deep link.
- A fresh session key is generated on your device and handed to joiners only through that QR / link — not uploaded as plaintext to Buzzio.
- Every message is encrypted on-device before it hits our relay.
- Joiners appear as anonymous slots — not as Buzzio IDs in the chat stream.
- When the timer ends (or you close the session), session data, keys, and relay paths are deleted.
We do not sell Whisper messages, session metadata, or who scanned your QR. Legal detail: /privacy · overview: /introduction · compare with: /one-to-one-chat.
Not the same product: Whisper Questions
Whisper Questions is a separate feature. It is anonymous Q&A via share links — someone posts a question link; strangers answer; the link owner reads replies. It is not end-to-end encrypted like Whisper private chat, and it stores answers so the owner can read them. This page is about Whisper private chat (QR sessions) only.
What Whisper gives you
| Promise | What you get |
|---|---|
| Anonymous by protocol | Chat labels are creator / scanner — not Buzzio IDs exchanged between participants |
| Ephemeral session crypto | A new session key per Whisper room — not your long-lived 1-to-1 identity keys |
| We can’t read the transcript | AES-256-GCM on-device; servers relay ciphertext |
| Hard timer | You choose 1 hour → 168 hours (7 days); then delete |
| Zero durable Whisper graph after expiry | Session records + relay paths are purged — no lifelong Whisper address book on our side |
| Optional Vanish + Secure View | Extra disappearing / anti-capture tools for the active window |
How a Whisper session is established
The user story
- Create — Name the session, pick duration and max members, optionally turn on Vanish / Secure View.
- Share — Show a QR code or share a deep link. The link carries the session token and the session key.
- Join — Scanner validates the key against a hash we store server-side (so a forged key can’t enter). An atomic join assigns a slot index.
- Chat — Each scanner gets a private 1-to-1 lane with the creator (not a group free-for-all among all scanners). The creator sees an inbox of anonymous member slots.
- Expire / close — Timer hits, or creator closes early → wipe.
Where data lives during the session
| Layer | Role |
|---|---|
| Your device | Plaintext session key, local messages/media, nicknames you assign |
| Session record | Operational metadata (expiry, scan limits, settings, status) — not a readable chat archive |
| Encrypted relay | Short-lived encrypted message relay per slot |
| Live counters | Scan count, status, expiry for atomic joins |
End-to-end session crypto
Whisper is end-to-end encrypted. The crypto model is intentionally different from Buzzio 1-to-1 chat.
What Whisper uses
| Piece | What it means |
|---|---|
| Ephemeral session key | Creator generates 32 cryptographically random bytes on-device for this session only |
| Out-of-band key delivery | The key rides inside the QR / deep link — people who scan get the key; Buzzio servers store only a hash to verify joins |
| Per-slot key (HKDF) | Each anonymous member lane derives its own key from the session key and slot index |
| AES-256-GCM | Message bodies (and media file contents) encrypted with the slot key before upload / relay |
| Optional compression | Payload may be compressed before encryption (size efficiency — not a privacy downgrade) |
In one sentence: a brand-new session secret is shared via QR; each anonymous lane derives its own key; every message is AES-GCM sealed before Buzzio ever touches it.
What Buzzio stores for crypto integrity (not for reading you)
- A hash of the session key, so joiners prove they have the real key without us storing the key itself.
- The plaintext session key never lives on our servers as a decryptable message secret. It stays on creator/joiner devices (and in the QR/link you deliberately share).
How this differs from standard 1-to-1 chat encryption
| 1-to-1 chat | Whisper private chat | |
|---|---|---|
| Identity model | Tied to durable Buzzio IDs and long-lived messaging keys derived from your recovery phrase | Tied to a temporary session token + ephemeral session key |
| Handshake | X3DH + Double Ratchet (per-message evolving keys, forward secrecy across an ongoing relationship) | Shared session key via QR/link; HKDF per slot; AES-GCM per message |
| Key lifetime | Keys persist with the account / conversation relationship | New key every Whisper session; designed to die with the timer |
| Addressing | You message a known Buzzio ID / contact | You message an anonymous slot inside a QR room |
| After it ends | Local history can remain on devices; server durable “who talks to whom” graph empties when nothing is undelivered | Session + relay paths deleted; not meant to become a permanent contact thread |
Both are E2E. Whisper optimizes for anonymous, time-boxed meetings. 1-to-1 optimizes for ongoing private relationships with ratchet-style forward secrecy.
Forward secrecy note (honest)
Whisper’s secrecy model is session-scoped: compromise of one session’s key does not unlock other Whisper sessions or your 1-to-1 keys. Within a live slot, messages share that slot’s derived keying material (not a Double Ratchet step). If you need continuous ratchet evolution for a long-term contact, use 1-to-1 chat. If you need “this room dies in 6 hours,” use Whisper.
Anonymity model
Whisper is built so participants do not exchange Buzzio identity as chat addresses.
What participants see / don’t see
| Creator | Scanner (joiner) | |
|---|---|---|
| Sees the other’s Buzzio ID in-chat? | No — members show as anonymous slots (optional local nicknames the creator sets on-device) | No — creator identity is not shown as a Buzzio ID |
| Sender label on encrypted messages | Creator or scanner only | Same role labels |
| Your Buzzio ID shared to peer on join? | Not published into the chat protocol for peers | Join path does not write the scanner’s Buzzio ID into the session as a peer identity |
Joiners see an explicit notice: your Buzzio ID will not be shared; the creator’s identity is hidden from you.
How anonymity is enforced
- Message envelopes carry role labels (creator / scanner), not peer Buzzio IDs.
- Join does not attach scanner account IDs to the public session graph — scanners get a numeric slot and optional push token for that slot.
- Creator-facing inbox is slot-based (“Anonymous Member #3”), not a contact lookup of who scanned.
- Optional nicknames the creator types are local labels on the creator’s device — they do not become the other person’s Buzzio ID.
- When the session ends, the creator’s identity was never revealed as a durable peer address for that room.
Honest operational note
During an active session, Buzzio still needs enough operational data to deliver pushes and expire the room (see metadata below). That is session plumbing, not “you both become permanent contacts,” and it is deleted after expiry. Participant-to-participant anonymity in the chat stream is separate from momentary server routing needs.
Zero metadata after expiry
What “zero metadata” means for Whisper
After a Whisper session expires (or is closed) and cleanup runs, Buzzio does not keep a durable, searchable server archive of:
- that Whisper room’s message bodies (we never had plaintext),
- a lasting “these people Whisper-chatted” graph for that session,
- the live relay trees for that token.
That is the product claim: meet → talk securely → leave no lasting Whisper trail on our servers.
What exists during an active session
| Data | Why it exists |
|---|---|
| Session token + status (active / full / closed) | Address the room; know if it’s joinable |
| Expiry and created times | Enforce the timer |
| Max scans / scan count | Cap how many people can enter (presets up to 50) |
| Optional session name | Creator label for managing the room |
| Vanish / screenshot setting flags | Enforce rules joiners agreed to |
| Session key hash | Verify the QR key without storing the key |
| Encrypted creator routing fields needed for push | Notify creator of joins / messages |
| Creator and per-slot scanner push tokens | Wake phones for new encrypted traffic |
| Encrypted relay ciphertext | Relay until devices store locally (courier cleanup after delivery) |
| Receipt / view-once paths | Delivery / seen / once-view UX |
| Blocked-slot markers (if creator removes someone) | Safety / moderation inside the room |
Message bodies stay E2E ciphertext. Operational fields exist to run and delete the session — not to build advertising profiles.
What is purged once the session expires / closes
Server cleanup removes the session record and related relay trees — encrypted chats, receipts, scanner push tokens, live counters, and related notification paths for that token — plus scheduled safety-net jobs for expired or closed sessions.
On devices: local session rows, local messages, and session media folders are cleaned on expiry / leave / close.
After cleanup: we are not sitting on a Whisper social graph you can query later.
Vanish & Secure View
These are the same product ideas as in 1-to-1 — but how they attach differs.
Vanish mode (Whisper)
| Detail | Whisper behavior |
|---|---|
| When set | At session creation (creator chooses) — applies to the room |
| What it does | Messages auto-delete after seen, for both sides |
| TTL options | 5 seconds · 1 minute · 5 minutes · 1 hour · 6 hours |
| Join transparency | Joiners see Vanish listed under Security & Rules before they enter |
Secure View (Whisper)
| Detail | Whisper behavior |
|---|---|
| When set | At session creation — session-wide rule |
| What it does | Strengthens protection against screenshots / screen recording while viewing the chat |
| Platform reality | Strong OS-level block on Android; detection / mitigation on iOS; browsers are best-effort |
| Join transparency | Shown on the join confirmation when enabled |
Differences from 1-to-1
| 1-to-1 | Whisper | |
|---|---|---|
| Vanish | Often a mutual request / agree flow inside an existing chat | Creator sets at create; room rule for the whole Whisper lifetime |
| Secure View | Mutual mode — both sides agree; pending requests expire (~2 hours) | Create-time session rule; not a bidirectional request handshake |
| Disappearing chat timers (24h / 7d / 90d) | First-class on 1-to-1 | Whisper’s main clock is the session duration (1h–7d); Vanish is the short post-seen layer |
| Once-view / view-once media | Available on 1-to-1 | Also available inside Whisper (open once; short auto-clear window in viewer) |
Delete-after-expire
Exact expiry trigger
Whisper expiry is time-based from creation:
- Creator picks a duration: 1, 2, 3, 6, 24, 48, 72, 96, or 168 hours.
- Server stores an expiry timestamp.
- Joins are rejected once the timer has passed.
- Deletion is scheduled for that timestamp.
- Daily safety-net jobs also sweep anything already expired or closed.
Also early end: the creator can close the session immediately, which notifies joiners and tears the room down without waiting for the clock.
What gets deleted
| Artifact | Deleted? |
|---|---|
| Encrypted messages on the relay | Yes |
| Receipts / related relay trees for that session | Yes |
| Session record | Yes |
| Scan / slot linkage & scanner push tokens | Yes |
| Operational metadata (expiry, counts, settings, status) | Yes |
| Session key on devices | Yes — wiped with local session cleanup |
| Local messages & media for that Whisper | Yes — per leave / close / expiry cleanup |
| Creator ↔ slot participant linkage for that room | Yes — no durable Whisper relationship row left after purge |
Not deleted by Whisper expiry: your Buzzio account itself, your normal 1-to-1 contacts, or unrelated features. Only that Whisper room’s world ends.
Other Whisper features
| Feature | Why it matters |
|---|---|
| Creator inbox of anonymous slots | One QR can admit many people (up to your max); each gets a private lane with you |
| Max members presets | 1 / 5 / 10 / 25 / 50 — control how wide the QR is |
| Session name | Organize active Whispers (“Event desk”, “Meetup”) without revealing IDs |
| Local nicknames for slots | Creator-only labels so you can manage chaos — still not their Buzzio ID |
| QR + deep-link share | Pass the session key out-of-band: show the code |
| Courier-style relay | After a device stores a message locally, the relay copy is deleted |
| Delivery states | Sending → sent → delivered → seen ticks for UX (still on ciphertext envelopes) |
| View-once media | Open once; viewer auto-clears after a short window (~20s in-app) |
| Reply / reactions / delete-for-me / delete-for-everyone | Everyday chat controls that still respect the session crypto |
| Forward (text) into normal chats | Bridge a line out to a real contact if you later choose to — without turning Whisper into permanent history by default |
| Creator remove (block slot) | Kick a lane; wipe that slot’s relay data |
| Scanner leave | Voluntarily exit; free a scan slot; wipe local + that slot’s relay |
| Push without doxxing the chat | Notifications wake devices; content remains E2E |
| Freemium creation gate | Free accounts: create on a ~7-day cooldown; Buzzio Premium unlocks unlimited Whisper creates |
Voice/video calls remain a 1-to-1 private-surface story; Whisper is the QR anonymous messaging room.
How a Whisper message moves
Creator generates session key → embeds in QR / link
↓
Joiner proves key via hash → gets anonymous slot
↓
Device derives slot key → AES-GCM encrypts message / media
↓
Blind relay holds ciphertext briefly
↓
Peer device decrypts → stores locally → relay copy deleted
↓
Timer ends or creator closes → session + keys + linkage purged
Summary
Whisper is anonymous QR private chat — talk without exchanging Buzzio IDs in the protocol. Crypto is ephemeral E2E: a fresh 32-byte session key, HKDF per slot, AES-256-GCM. It is not the long-lived X3DH/Double Ratchet stack of 1-to-1; it is built to expire. After expiry, messages, keys, session record, and participant linkage are gone. Vanish and Secure View are available as create-time room rules. Max members: up to 50 anonymous slots per session; duration: 1 hour to 7 days.
Related: /introduction · /one-to-one-chat · /groups · /privacy · /terms