Core Concepts

This page explains the fundamental concepts in Static. Understanding these will help you make sense of how the app works, what the privacy settings do, and why certain things behave the way they do.

Communities

A community is the top-level organizational unit, equivalent to a Discord server or a Slack workspace. Each community has:

A name chosen by its creator.
One or more channels for text and voice communication.
A member list with role-based permissions (Owner, Admin, Moderator, Member).
An invite code that can be shared to allow new members to join.

Communities are identified by a 32-byte cryptographic ID derived from the community’s MLS group. There is no central registry of community names — two communities can have the same name without conflict.

Anyone can create a community. The creator automatically becomes the Owner, with full control over channels, roles, and settings.

Channels

Channels exist within communities and come in three types:

Text channels — For sending and receiving encrypted text messages. Each text channel maintains its own MLS encryption group, meaning each channel has independent encryption keys.
Voice channels — For real-time voice and video communication. Voice uses LiveKit (WebRTC SFU) with end-to-end encryption, where media encryption keys are derived from the channel’s MLS group secrets.
Direct messages (DMs) — Private conversations between two users. DMs are implemented as 1:1 MLS groups with deterministic channel IDs derived from both participants’ public keys.

Each channel has its own MLS encryption group. This means that adding someone to a community does not automatically give them access to every channel. Channel-level access is controlled by MLS group membership.

Threads share the parent channel’s MLS group — they do not create separate encryption groups.

Identity

Static uses a cryptographic identity model with no central authority. Your identity is a key pair, not a username/password combination.

Master Key

When you create your identity, Static generates an Ed25519 master key pair. The 32-byte public key is your permanent user ID. This key:

Is generated entirely on your device.
Never leaves your device’s secure storage.
Is not registered with any server or directory.
Serves as the root of trust for all your devices and credentials.

Device Keys

Each device you use gets its own delegated device key pair, signed by your master key. This means:

You can use Static on multiple devices without sharing your master key.
If a device is compromised, you can revoke just that device’s key without losing your identity.
Each device has independent MLS credentials for group encryption.

Recovery Phrase

Your recovery phrase is a 24-word BIP-39 mnemonic that encodes your master key. It is the only backup mechanism for your identity.

If you lose all your devices, the recovery phrase lets you regenerate your master key and re-establish your identity. Without it, your identity is permanently lost — there is no server-side recovery, no “forgot password” flow, and no customer support that can restore it.

Think of the recovery phrase like a hardware wallet seed phrase: write it on paper, store it securely offline, and never enter it on a device you do not trust.

Petname System

Static uses a three-tier display name system:

Petname — A name you assign locally to another user (only visible to you).
Nickname — The display name the user chose for themselves.
Key fingerprint — A truncated version of their public key, used as a fallback when no name is available.

The client displays whichever is available, in that priority order. Petnames are stored locally and never sent over the network.

Encryption: MLS Protocol

Static uses the Messaging Layer Security (MLS) protocol for all message encryption. MLS is an IETF standard (RFC 9420) designed for efficient group messaging with forward secrecy and post-compromise security.

What MLS Provides

End-to-end encryption — Messages are encrypted on your device and can only be decrypted by other members of the channel. The supernode, relay operators, and anyone else in the network path see only opaque ciphertext.
Forward secrecy — Compromising a key today does not expose past messages. Keys are ratcheted forward with each epoch transition.
Post-compromise security — If a member’s key is compromised and then rotated, future messages are again secure. The attacker loses access after the next key update.
Efficient group operations — Adding or removing a member requires a single Commit message, not O(n) pairwise updates. This scales to hundreds of members per channel.

How It Works in Practice

Each channel has its own MLS group. When you send a message:

Your client encrypts the plaintext using the current MLS group key.
The ciphertext is a single blob that any group member can decrypt (but nobody else).
The ciphertext is padded, batched, and sent to the supernode.
The supernode fans out the ciphertext to all online members.
Each recipient’s client decrypts it locally.

When members join or leave, an MLS Commit updates the group state and rotates keys. The ciphersuite used by default is MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 — a well-established classical cryptographic configuration.

Commit Ordering

MLS requires that group operations (adding members, removing members, updating keys) are applied in a consistent order by all members. Static uses a single-committer pattern: the community’s supernode acts as the ordering authority for MLS Commits. It accepts the first valid commit for each epoch and rejects conflicting ones.

This is a pragmatic choice for reliability. A decentralized alternative (DMLS) is planned for future phases when the IETF specification matures.

Supernodes

A supernode is a persistent server that facilitates community operations. It is analogous to a Matrix homeserver or a Discord backend server, but with a critical difference: the supernode cannot read message content.

What Supernodes Do

Relay encrypted messages — Fan out MLS ciphertext to all online channel members.
Order MLS Commits — Act as the MLS Delivery Service, ensuring consistent group state.
Archive encrypted history — Store encrypted ciphertext so members who were offline can catch up.
Bridge push notifications — Wake up mobile clients via APNs/FCM when messages arrive.
Track presence — Optionally track who is online (opt-in per member).

What Supernodes Cannot Do

Read message content — All messages are MLS-encrypted before reaching the supernode. The supernode handles opaque ciphertext.
Forge messages — All messages carry cryptographic signatures that recipients verify.
Impersonate members — MLS credentials are verified client-side against known public keys.

What Supernodes Can See

This is important to understand honestly:

Who sends messages — The supernode knows which connection sent a message (though relay routing hides the sender’s IP address).
When messages are sent — Message timing is visible to the supernode (mitigated by batched delivery).
Which channels messages go to — Channel IDs are in the clear because the supernode needs them for routing.
Message sizes — Visible as ciphertext lengths (mitigated by padding to fixed-size buckets).

The supernode sees communication metadata but not content. Static’s privacy layer (relay routing, ephemeral sessions, padding, batching) works to minimize even this metadata exposure. See the Privacy Model for a full analysis.

Hosting Options

Anyone can run a supernode — self-host on your own hardware for free, or use a hosted supernode starting at $5/month. The privacy guarantees are identical either way: the supernode only handles encrypted data it cannot read. See the Self-Hosting Guide for self-hosting setup instructions.

Local Storage

All decrypted message content is stored locally on your device in an encrypted SQLite database (SQLCipher). The database is the single source of truth for your message history.

Key properties of local storage:

Encrypted at rest — The database is encrypted with SQLCipher. The encryption key is derived from your identity key material.
Full-text search — An FTS5 index is maintained over decrypted messages, enabling fast local search.
Offline access — Because messages are stored locally, you can read your full history without a network connection.
No cloud sync — Your message database exists only on your device. It is not uploaded, backed up, or synced to any server. If you lose your device without a backup, local message history is lost.

Privacy Layer

Static includes a custom privacy layer that sits between the application and the Iroh networking stack. It provides defense-in-depth against traffic analysis:

Relay routing — All traffic goes through Iroh relays by default, hiding your IP address from supernodes and peers.
Ephemeral session keys — Each app session uses a fresh network identity, preventing cross-session correlation.
Message padding — All messages are padded to fixed-size buckets (256B, 1KB, 4KB, 16KB) so observers cannot infer content type from size.
Cover traffic — Optional dummy messages at configurable intervals to mask activity patterns (disabled by default to save bandwidth).
Batched delivery — Outgoing messages are queued and sent in periodic batches rather than immediately, reducing timing correlation.

For a thorough analysis of what is and is not protected, read the Privacy Model.