Expand description
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 stringcontentfield. - 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
MessageinSTATEunder 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).
- invite_
list - Cross-device public-invite sync — the encrypted Invite List.
- 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.
- v2
- Concord v2 (the upstream CORD specs —
github.com/concord-protocol/concord). - version
- Per-entity version chain for authority editions.
Structs§
- Channel
- A Channel inside a Community: its own independent key, current epoch, and name.
- Channel
Id - A Channel’s stable identity within a Community. Same opaque-random rule as
CommunityId; doubles as the addressable metadatad-tag. - Channel
Key - A 32-byte symmetric channel secret — the raw NIP-44 v2
ConversationKeymaterial. Zeroized on drop; never logged. - Community
- A Community (Discord’s “server”).
- Community
Id - A Community’s stable identity = a random 32-byte opaque id (NOT a timestamp-encoding snowflake, which would leak creation time).
- Community
Image - 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
ztag. Opaque 32 bytes; outsiders can’t link it across epochs or to an identity. - Server
Root Key - The server-root /
@everyonekey: always minted, always distinct from any channel key. Gates metadata + roster + roleless channels. Zeroized on drop.
Enums§
- Concord
Protocol - Which Concord protocol a community runs. Vector carries both for a migration
window: v1 (the shipped
#z-addressed stack) and v2 (the self-certifying-id CORD stack,community::v2). Persisted as thecommunities.protocolinteger.
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::ServerRootuses the all-zeroid32sentinel). AChannelIdis random-32, so it can never collide with this — letting onecommunity_epoch_keystable 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.