Vector Messenger

vector-core is the headless engine for Vector, providing the following protocol logic:

• NIP-17 gift-wrapped DMs: Support for sending, replying, editing, deleting, reactions (including NIP-30 custom emojis), typing indicators, and read states.
• Communities (Concord): An end-to-end-encrypted Discord-style protocol over Nostr featuring epoch-keyed channels, roles, capabilities, invites, and bans/kicks with read-cut rekeys.
• Encrypted files: NIP-96 / Blossom uploads with progress tracking, retries, and server failover. Uses AES-GCM at rest and hash-based deduplication. Also supports unencrypted public-image uploads for avatars/banners.
• Profiles: Fetching, updating, status management, blocking, local nicknames, and a prioritized background sync queue.
• Storage & Crypto: Per-account SQLite storage with atomic migrations, a GuardedKey vault for secrets, Argon2id, AES-GCM, ChaCha20, and SIMD-accelerated hex operations.
• Resilience: NIP-77 negentropy sync and an event-driven relay health monitor for automatic reconnection and data recovery.

Concord is the end-to-end encrypted protocol powering Vector's Communities. It provides a Discord-style group chat experience without a central server. Instead of a company-controlled database, Concord uses a decentralized model where authority and membership are managed through cryptography.

Key characteristics:

• No Central Server: There is no single computer or company that holds your messages or controls access.
• Key-Based Membership: Being a member of a community or channel is defined by possessing the corresponding cryptographic key. If you can decrypt the room, you are in it.
• Decentralized Authority: Moderation (owners, admins, kicks, bans) is managed via a signed roster that members can independently verify using math, rather than relying on a central authority's permission.
• End-to-End Encryption: Messages are encrypted such that the relays passing them cannot read them.

When a message originates from a community, you can access the sender as a member to perform moderation tasks.

Member Moderation

If msg.member() returns Some(member), you can use:

• member.kick().await? / member.ban().await? / member.unban().await?
• member.grant_admin().await? / member.revoke_admin().await?
• member.is_admin() to check status.

Community Management

You can manage communities directly via the bot or an incoming message:

• bot.community(community_id) or msg.community()
• community.invite("npub1...").await?
• community.create_invite().await? (returns an invite link)
• community.members().await (iterates through members)

Joining Communities (Auto-accept)

Configure how your bot handles community invites during the build process:

• Accept from anyone: .public()
• Whitelist only: .whitelist(["npub1owner..."])

if let Some(member) = msg.member() {
    member.kick().await?;
    member.grant_admin().await?;
    if member.is_admin() { /* ... */ }
}

// Or manage a community directly:
let community = bot.community(community_id);
community.invite("npub1...").await?;
let link = community.create_invite().await?;
for m in community.members().await { /* ... */ }

Vector uses a specialized vault architecture to protect private keys from automated extraction, forensic imaging, and reverse engineering. Instead of storing keys as contiguous values, the vault employs several layers of obfuscation:

1. Secret Splitting: Each key is XOR-split into 4 random shares.
2. Scattered Storage: These shares are stored as individual usize values across 128 static arrays.
3. Decoy Arrays: Only a few arrays contain real data; the remaining arrays are indistinguishable decoys filled with identical random values.
4. ASLR-Derived Positioning: Share positions are derived from ASLR (Address Space Layout Randomization) addresses that change every launch, ensuring no two positions collide.
5. Dynamic Derivation: All derivation logic uses zero compile-time constants; multipliers and iteration counts are computed from runtime ASLR addresses.

Key Properties

• Zero heap allocations: No pointers or allocation metadata are used, preventing structural fingerprints.
• Zero searchable constants: No magic numbers exist in the binary for reverse engineers to find.
• Indistinguishable arrays: All 128 arrays share identical size, content distribution, initialization timing, and modification patterns.
• Snapshot-diff resistance: During storage, all 128 arrays receive random writes to make real writes invisible to memory diffing tools.
• Multi-key isolation: Multiple keys (e.g., signing vs. encryption) share the same vault arrays without corrupting each other, as decoy writes exclude positions belonging to other active keys.
• Zero side-channel: Key retrieval uses only atomic reads (no memory writes).
• Computational hardening: Thousands of mixing iterations are used per derivation to make brute-force attacks expensive.

A Concord Community is a top-level space (similar to a Discord server) composed of several Channels (similar to #general or #announcements).

The Core Components

• People: Identified by their personal keypairs (Nostr npub). This identity is used to sign all actions for verification.
• Community: Anchored by a master community key and an owner. The owner is proven via an owner attestation (a signed certificate).
• Channels: Individual rooms within a community. Each channel has its own unique channel key, ensuring that conversations in one room are cryptographically separate from others.
• Relays: Public, interchangeable Nostr relays that act as "dumb mailboxes." They store and forward encrypted blobs but cannot read the content or identify specific users within a community.
• Roster: A signed list that records the roles (Owner, Admin, Member) of participants, allowing members to verify authority locally.