Groups

Buzzio groups are for friends, teams, trips, and circles that need more than a 1-to-1 thread — without pretending every room needs the same secrecy model.

At create time you pick two axes:

1. How history works — end-to-end (E2E) or open-history
2. How long the group lives — permanent or temporary (up to 30 days)

That gives four real products:

We do not sell group messages, member lists, invite tokens, or open-history archives. Legal detail: /privacy · overview: /introduction · 1-to-1 baseline: /one-to-one-chat.

---

The four group types

1. Permanent E2E group

Ongoing private circle. Message bodies are end-to-end encrypted. Buzzio relays ciphertext for catch-up, then purges relay buckets. Readable history lives in the locally encrypted database on each member’s devices. New people who join later get keys for future traffic — not a full archive of the past.

Best for: close friends, family, private teams, sensitive circles.

2. Temporary E2E group

Same encryption model as permanent E2E — plus a hard lifetime (1 hour → 30 days). When the window ends, the group is deleted by design: server group state cleaned, members notified, local chat wiped.

Best for: weekends, trips, exams, short projects, anything that should not sit in everyone’s group list forever.

3. Permanent open-history group

Shared room with durable encrypted history. Later joiners can scroll past messages. Encryption uses a server-held data encryption key so history delivery works across members and devices. That is not the same as E2E — and we say so upfront.

Best for: clubs, classes, long-running projects, groups that onboard people mid-way.

4. Temporary open-history group

Open history while the group is alive, then expiry deletes the group and wipes open-history messages, keys, and media for that room.

Best for: events and pop-up communities that still need “catch me up” history during the window.

---

E2E groups vs open-history groups

E2E: how group keys work

Buzzio E2E groups use sender-key group crypto on top of your existing 1-to-1 Double Ratchet sessions:

1. Each member generates their own sender key material for that group on device.
2. They distribute that material to other members as encrypted control messages — protected by pairwise E2E, not as plaintext on the wire.
3. Group messages are sealed with the sender’s chain; peers who received that distribution can decrypt.
4. Servers see ciphertext + routing, not readable text. After catch-up windows, durable readable E2E archives are not kept.

What that means for you: adding someone distributes current keys so they can join the conversation going forward. It does not reconstruct an open cloud transcript of everything said before they arrived.

Open-history: how the shared key works

1. The creator provisions a data encryption key for the group.
2. The server stores a wrapped copy so current members can obtain it to encrypt and decrypt room content.
3. Text and media are encrypted under that key before durable storage.
4. History APIs page encrypted history back to authorized members — that is the product: shared continuity.

Honest line: open-history is encrypted at rest with keys Buzzio holds for the feature. It is built for rooms, not for “Buzzio is blind forever.”

Who can decrypt history?

---

Permanent vs temporary

Temporary is not a soft “maybe delete someday.” It is a scheduled lifetime.

Expiry options

At create time you choose a duration preset:

1h · 2h · 6h · 12h · 1d · 2d · 3d · 7d · 10d · 14d · 20d · 30d
(max 720 hours / 30 days)

Delete runs when the earliest of these hits: the scheduled expiry, an optional custom destruct time, or dissolve/delete by an authorized role. Same duration options apply to temporary E2E and temporary open-history.

What gets wiped when a temporary group expires

1. Members get a push so clients can react.
2. Open-history: durable messages, keys, and feature media for that group are wiped.
3. Group document and related relay / receipt state are removed; group image cleaned.
4. Clients clear local group chat for that room so the conversation does not linger as a normal thread.

Permanent groups have no auto-expiry. They live until dissolve/delete by authorized roles. Permanent join hygiene includes a join-attempt cap (3) and banned members who cannot self-rejoin after admin removal.

Changing type after create

Encryption mode (E2E ↔ open-history) and permanence (permanent ↔ temporary) are chosen at creation. There is no “switch history mode later” path — pick the room that matches the job up front.

---

Encryption behavior per mode

E2E (permanent or temporary)

Open-history (permanent or temporary)

Delete-for-everyone windows

• Open-history delete-for-everyone window is short (on the order of a few hours).
• E2E / relay group delete coordination uses a longer coordination window (on the order of a day) for undelivered / peer cleanup.

Deletes are coordinated membership tools, not a Buzzio-readable undo log.

---

Vanish and Secure View in groups

These names match 1-to-1 for product clarity — but group implementation is not identical to the mutual 1-to-1 handshake.

Secure View / screenshot protection

Trust note: iOS / web cannot always fully block OS screenshots the way Android can. Buzzio detects and mitigates in-app where possible; treat capture protection as hardening, not a physical law.

Vanish mode

View-once media in groups

Group view-once media uses a dedicated viewer with screen security, a short auto-clear open window (~20s), and no “opened” receipt pinged to the sender the way some 1-to-1 once-view flows behave — to reduce notification side-channels in multi-member rooms.

---

Roles: Super Admin vs Admin

History mode, permanence, vanish, and Secure View are set when the group is born. Day-to-day power is membership, roles, invites, pins, and moderation gates.

---

Invite links and join security

Invite links carry group id + invite token + display name encoding — not encryption keys and not your 12-word phrase.

Regenerating the token invalidates old links. Share links like door codes: treat regeneration as the emergency lock change.

Invites are for membership, not for bypassing E2E key distribution or grabbing someone else’s private keys.

---

Everyday group features

At larger member counts (≥ ~100), per-message push wake may be batched for scale — members still get messages via normal sync paths. The privacy model does not flip because of push batching.

Groups stay the focused small/mid room. For Discord-scale roles, channels, and events, see Communities.

---

Metadata honesty

“Zero metadata” for 1-to-1 (no durable who-talks-to-whom graph when nothing is undelivered) is a private 1-to-1 claim. Groups necessarily keep membership and roles — that is administration, not a sold social graph for ads.

---

How to choose

---

Summary

Groups offer four real modes: E2E or open-history × permanent or temporary. E2E groups use sender-key crypto; Buzzio cannot read message bodies; relay catch-up is short (~5 days), not a cloud inbox. Open-history groups use a server-held key for shared encrypted continuity — honestly labeled. Temporary groups use concrete timers up to 30 days, then wipe. Vanish and Secure View are create-time controls (Vanish on E2E; Secure View on both). Super Admin owns critical settings and invite regeneration; Admins run day-to-day membership and pins. Invite links carry tokens, not keys; optional password hash, approval, bans, and a 500-member cap.

Related: /introduction · /one-to-one-chat · /communities · /privacy · /terms