Communities
Buzzio Communities are shared servers — not private 1-to-1 chats and not small Groups. They give you categories, text channels, roles, events, invites, and moderation, with an honest crypto label: server-held data encryption keys, so history and multi-device continuity work for thousands of members.
In plain terms:
- You create a community (a server) with a name, optional password, and optional join approval.
- Under it live categories → text channels (open or password-locked).
- Roles — Everyone, Creator, Creator Admin, and custom roles — control who can invite, moderate, manage structure, and post.
- Events let members mark Interested; location can be text, a link, or a community channel.
- Content is encrypted at rest under community / channel keys Buzzio holds for the feature.
We do not sell community data — not channel messages, member lists, role maps, event RSVPs, invite tokens, or audit logs. Legal detail: /privacy · /terms · overview: /introduction.
What’s inside a community
Communities are separate from Groups. A Group is one chat room. A Community is a home with many text channels, roles, and events — Groups are not placed inside Communities.
Inside a community you can:
- Organize the sidebar with categories and text channels (open, or locked with a password)
- Chat with messages, pins, and media in those channels
- Assign roles so people can invite, moderate, or manage rooms
- Review members, bans, and join requests
- Create events where members mark Interested
- Share invites (including temporary ones) and review audit logs if you have permission
What seeds on create
| Entity | Default |
|---|---|
| Category | Welcome |
| Channel | #general — default, open, inside Welcome |
| Role | Everyone with safe invite / view defaults |
Channels without a category appear under an uncategorized area in the hub. There are no voice channels — text channels only.
Communities vs Groups
| Communities | Groups | |
|---|---|---|
| Structure | Server → categories → many channels | Single room |
| Typical size | Clubs, schools, creators (up to 10k) | Circles / teams (smaller cap) |
| Crypto | Server-held community / channel keys | E2E sender keys or open-history keys |
| Roles | Discord-style permission matrix | Super Admin / Admin |
| Events | First-class community events | Not this product |
Use Groups when the product is one conversation. Use Communities when the product is a home with rooms, roles, and calendars.
Encryption model (server-held keys)
Communities use a server-held shared encryption key model. Message bodies and media are encrypted so storage is not plaintext — but Buzzio can unwrap keys for authorized members. That is how late joiners, multi-device sync, and password-channel gating work at community scale.
Honest line: Communities are encrypted shared rooms, not operator-blind E2E. If you need Buzzio-blind message bodies, use 1-to-1, Whisper, or E2E Groups.
How community keys work for members
| Moment | What happens |
|---|---|
| Create community | Creator receives the community key so they can start encrypting |
| Join (invite / password / approval) | After membership succeeds, the member can obtain the community key |
| Open channel message | Encrypt/decrypt with the community key |
| Password channel | Member must unlock the channel with its password; then they get that channel’s dedicated key |
Membership is the gate. Leave, kick, or ban → key fetch stops for that account.
Per-channel keys vs the community key
| Channel visibility | Key used for channel content |
|---|---|
| Open | Shared community key |
| Password | Dedicated channel key |
Converting a channel to password:
- Generates a new channel key
- Resets channel membership to the editor (others must re-join with the password)
- Open → password is a real key boundary, not a cosmetic lock
Switching password → open returns that channel to the community key model.
Rotation on membership change
The community key is not automatically rotated on every leave, kick, or ban.
| Event | Key behavior |
|---|---|
| Member joins | Gains access to the current key(s) their membership allows |
| Member leaves / kicked / banned | Server stops issuing keys via membership checks |
| New key created | Community create; or new key when a channel becomes password-locked |
Cutting membership stops cloud key fetch and future authorized sync. A former member who already cached a key on a compromised device is a device-security problem — we do not pretend a leave event rewrites every historical ciphertext. Treat bans and device discipline as part of community hygiene.
Roles: Everyone, Creator, Creator Admin, custom
| Role | Persistent? | Assignable? | Default power |
|---|---|---|---|
| Creator | Virtual (always the community creator) | No | All permissions, always |
| Creator Admin | Yes | Yes (creator-gated) | All permissions; cannot remove the creator |
| Custom roles | Yes | Yes | Whatever you toggle |
| Everyone | Yes | Implicit — all members | Invite people, view audit logs, view members (tunable) |
How custom roles work
Each custom role stores a name, optional color, display order, a map of permissions, and which channels the role may edit when it has channel-edit rights.
Setup templates at create (gaming, school club, study group, friends, artists/creators, local community, or build your own) are shortcuts for name and vibe — they use the same permission engine.
How permissions resolve
Buzzio Communities use additive OR, not Discord-style deny-overrides:
- Creator → every permission.
- Else Creator Admin / administrator grant → every permission (cannot remove the creator).
- Else merge Everyone + all assigned custom roles — any grant wins.
- Optional community flag can hide the member list from non-privileged members.
Display order is sort only. Higher position does not override lower roles the Discord “higher role wins” way. Grant carefully: permissions accumulate.
Channel-level permission overlays
Separate from community roles, each channel can restrict:
- Who can view — role lists (open channels default to Everyone; password channels start restricted)
- Who can send/react — per-action grants (text, GIF, sticker, image, video, voice, react)
Administrators with the community administrator grant bypass channel-specific restrictions (including seeing password channels they’re entitled to by that grant).
When a role is deleted
You cannot delete Everyone or Creator Admin. Deleting a custom role strips that role from members immediately — they keep Everyone defaults and any other roles still assigned. Treat “delete role” as removing a grant bundle, not rewriting history.
Full permissions list
Community-level permissions
| Permission | What it allows |
|---|---|
| Create channels | Create new text channels |
| Edit channels | Edit name, visibility, settings for allowed channels (channel creators can always edit theirs) |
| Create categories | Create and organize categories |
| Create events | Schedule community events |
| Manage events | Edit/delete events created by others |
| View audit logs | Read the community audit log |
| Invite people | Share invite links |
| Ban & remove members | Remove or ban members |
| Delete other messages | Delete others’ messages for everyone in a channel |
| Pin and unpin messages | Pin/unpin in channels |
| Can tag | Use @everyone, @here, @role, @username style tags |
| Bypass slow mode | Ignore restricted messaging for new members |
| Manage roles | Create roles and assign them |
| Modify description | Edit community description |
| Modify rules | Edit community rules text |
| View member list | See full member directory |
| Create temporary invite links | Time-limited invites |
| Create temporary channel passwords | Temp passwords for locked channels |
| Administrator | All permissions + bypass channel restrictions; cannot remove/ban the creator |
Everyone defaults (out of the box): invite people, view audit logs, view members.
Grouped in the role editor: Structure · Moderation · Invites (plus the separate administrator toggle).
Channel message permissions
| Permission | UI label |
|---|---|
| Send text | Send text messages |
| Send GIF | Send GIFs |
| Send sticker | Send stickers |
| Send image | Send images |
| Send video | Send video files |
| Send voice | Send voice messages |
| React | React to messages |
Creator-only action
| Action | Who |
|---|---|
| Assign Creator Administrator | Creator only |
Events: Interested RSVP & location types
What an event stores
| Field | Purpose |
|---|---|
| Title, description | What / why |
| Start / end | Schedule window |
| Frequency | None, daily, weekly, or monthly |
| Location type + location fields | Where (see below) |
| Optional cover image | Visual |
| Authorship / ordering | Who created it, when, sort order |
| Interested count | Denormalized RSVP tally |
Edit/delete: event creator with create-events permission, or anyone with manage-events.
Location types
| Type | Meaning | Privacy note |
|---|---|---|
| Text | Free-form place / address / informal note | Visible to community members who can see the event — treat addresses as shared club info |
| Link | Virtual meeting (http/https URL) | Same member visibility; don’t put secret join codes in events visible to a large room |
| Channel | Meet in a Buzzio channel (#…) | Points inside the community — no external address leak |
“Interested” RSVP
| Step | Behavior |
|---|---|
| Member taps Interested | Records interest for that event |
| Counter | Interested count updates atomically |
| Lists | Members can see who is interested |
RSVP visibility & privacy
- Not anonymous. Any community member can see who marked Interested.
- Outside the community: RSVPs are not a public web directory.
- Marking Interested shares your Buzzio identity with fellow members, not with advertisers. We do not sell RSVP graphs.
Other community features
Channel categories
Full create / rename / reorder. Default Welcome + #general pattern matches familiar muscle memory.
Rules & onboarding
| Feature | Behavior |
|---|---|
| Community rules text | Editable with modify-rules; shown from hub / settings |
| Per-channel rules | Optional channel-specific rules |
| Setup | Name, optional community password (≥4 chars), require-member-approval |
| Welcome UI | Empty #general shows a welcome view; post-create hub banner |
| Forced “accept rules” before join | Rules are visible guidance — not a hard gate |
Join gates
| Gate | Purpose |
|---|---|
| Invite token / QR / deep link | Primary join path |
| Optional community password | Checked at join |
| Optional approval queue | Join requests until an authorized member approves — no encryption key until approved |
| Channel password | Separate lock + channel key |
| Bans | Blocked from rejoin |
There is no community government-ID check. Access = invite + optional password + optional approval.
Discovery & search
| Feature | Present? |
|---|---|
| Public community directory / browse marketplace | No |
| Join by community ID + invite/password | Yes |
| Invite deep links / QR | Yes |
| In-hub channel / category search | Yes |
| Member list / mention search | Yes |
Discovery is intentional (share a link), not a sold public catalog of every community.
Member limits & scale
| Limit | Value |
|---|---|
| Hard member cap | 10,000 |
| Soft “large community” tip | ~5,000 — recommend tags-only notifications; admin decides |
Join / approve fail when full.
Restricted messaging (slow mode)
Levels: none · low · medium · high · highest — rate-limits new members. Bypass with bypass-slow-mode permission.
Notifications
Per-member level: all · mentions · none. Community can push tags-only (especially useful near the large-community tip).
Channel hardening extras
Per channel (where enabled): screenshot protection (Secure View–class hardening) and vanish mode with TTL. OS screenshot blocking has platform limits; harden, don’t promise physics.
Audit logs
Membership and moderation actions can land in audit logs for members with view-audit-logs. Oversight for organizers — not an advertising feed.
Metadata honesty
| Surface | Readable channel archive for Buzzio? | Durable admin state? |
|---|---|---|
| Community open channels | Encrypted under server-held community key (feature needs it) | Yes — members, roles, bans, invites, events, audit |
| Password channels | Encrypted under channel key; still server-held wrap model | Yes — plus channel membership |
| After leave / ban | No further key issue to that account | Membership & ban records as needed to run the server |
“Zero metadata” for private 1-to-1 is a sealed conversation claim. Communities necessarily keep membership, roles, events, and invites — that is how a multi-channel home runs. It is administration, not a sold social graph.
How to choose
| If you want… | Choose |
|---|---|
| One private circle / trip room | Groups |
| Operator-blind message bodies | E2E Groups or 1-to-1 / Whisper |
| Many channels, roles, events, moderation | Communities |
| Late joiners who can read shared channel history | Communities (server-held keys) — by design |
| A locked topic inside the same server | Password channel (separate channel key) |
| Announce to followers without chat chaos | Broadcast Channels |
Summary
Communities are Discord-shaped: community → categories → text channels — separate from Groups. Crypto is honest: server-held community key for open channels; dedicated key for password channels — not E2E. Keys are membership-gated; the community key is not auto-rotated on every leave. Roles include Everyone, Creator, Creator Admin, and custom roles with additive permissions. Nineteen community permissions plus per-channel send/react overlays are enumerable. Events support Interested RSVP with locations as text, link, or #channel. Join by invite / ID, optional password and approval; no public marketplace dump. Hard cap 10,000 members, with slow mode, tags, and audit logs for real moderation.
Related: /introduction · /groups · /broadcast-channels · /privacy · /terms