Module community 

Vector Community protocol (GROUP_PROTOCOL.md).

A Community is the top-level container (Discord’s “server”, but Vector is serverless so the name reflects that); it holds Channels. This module is the cryptographic core: the frozen key-derivation convention and the message envelope. It is pure, network-free, and DB-free — the riskiest unknowns isolated for exhaustive unit testing before anything depends on them.

Modules

attachments

Community message attachments (NIP-92 imeta).

cache

Per-account RAM cache for Community sync state.

cipher

Raw-key NIP-44 v2 sealing — the single symmetric-encryption primitive of the Community protocol. The channel key (message plane) and the server-root key (metadata plane) are both raw 32-byte ConversationKeys; ciphertext is base64’d for carriage in an event’s string content field.

derive

Key-derivation convention (GROUP_PROTOCOL.md) — FROZEN.

edition

Real-npub authority editions — the keyless model’s authorship + version carrier.

envelope

Message envelope (GROUP_PROTOCOL.md).

inbound

Inbound processing: turn a verified, opened Community message into a Message in STATE under its channel chat (→ app state). Pure conversion (build_message) is separated from the STATE mutation (ingest_message) so the conversion is unit-testable without any global state.

invite

Targeted invites (GROUP_PROTOCOL.md).

list

Cross-device joined-communities sync — the encrypted Community List.

metadata

Control-plane metadata CONTENT structs (GROUP_PROTOCOL.md).

owner

Owner attestation — the unforgeable binding of a Community to its owner’s identity ( “anchored to the owner’s identity key”).

public_invite

Public (link) invites (GROUP_PROTOCOL.md).

realtime

Realtime Community (Concord) subscription, routing, dispatch, and control-follow.

rekey

Rekey blob primitive (GROUP_PROTOCOL.md).

roles

Concord role graph (GROUP_PROTOCOL.md).

roster

Folding fetched authority editions into the current roster.

send

Sending and fetching Community channel messages over a Transport.

service

Orchestration that ties the Community send/delete primitives to persistence, with multi-account safety. This is the layer Tauri commands are thin wrappers over: it publishes a message AND retains its ephemeral key (so the sender can later delete it), and deletes by loading that retained key back.

transport

Transport abstraction for Community events.

version

Per-entity version chain for authority editions.

Structs

Channel

A Channel inside a Community: its own independent key, current epoch, and name.

ChannelId

A Channel’s stable identity within a Community. Same opaque-random rule as CommunityId; doubles as the addressable metadata d-tag.

ChannelKey

A 32-byte symmetric channel secret — the raw NIP-44 v2 ConversationKey material. Zeroized on drop; never logged.

Community

A Community (Discord’s “server”).

CommunityId

A Community’s stable identity = a random 32-byte opaque id (NOT a timestamp-encoding snowflake, which would leak creation time).

CommunityImage

A reference to an encrypted image blob (community logo/banner), using the same technique as NIP-17 file attachments: a fresh random AES-GCM key+nonce encrypts the image, the ciphertext is uploaded to Blossom, and this reference travels inside ServerRoot-sealed metadata. So possession of the server-root key (every member) gates the image, and there is no key reuse across images.

Epoch

The epoch counter — the read-access clock (“two clocks”). Bumps only on a rekey; stamped explicitly even when it is 0, so multi-channel and rotation stay additive (forward-compat hook #1).

Pseudonym

Per-epoch pseudonym = the value carried in the relay-filterable z tag. Opaque 32 bytes; outsiders can’t link it across epochs or to an identity.

ServerRootKey

The server-root / @everyone key: always minted, always distinct from any channel key. Gates metadata + roster + roleless channels. Zeroized on drop.

Constants

MAX_COMMUNITY_RELAYS

Protocol cap on a Community’s relay set (§ transport). More relays are needless and amplify resource + metadata-exposure cost; 5 gives redundancy without centralisation. Enforced by truncate-on-read at every Community/CommunityInvite construction boundary, so a hostile or legacy bundle degrades to ≤5 distinct relays rather than being honored or rejected.

SERVER_ROOT_SCOPE_HEX

The all-zero hex scope id for server-root-scoped epoch keys (RekeyScope::ServerRoot uses the all-zero id32 sentinel). A ChannelId is random-32, so it can never collide with this — letting one community_epoch_keys table hold both channel keys and the base/server-root key keyed by (scope_id, epoch).

Functions

cap_relays

Dedupe (order-preserving) + truncate a relay set to MAX_COMMUNITY_RELAYS. Dedup first so the cap means “up to 5 DISTINCT relays” — a bundle padding one relay 5× can’t waste the budget.