TELECOM

Private, pseudonymous desktop messenger. Rust core, no phone number, no email, no directory.

Prototype stage, unaudited. Read docs/threat-model.md before trusting it with anything sensitive.

What it does

• 1:1 messaging over the Olm Double Ratchet (vodozemac, an audited implementation), forward secrecy per message.
• Hybrid post-quantum first contact: every pre-key handshake frame is wrapped in ML-KEM-768 on top of X25519, so recording today's traffic and breaking X25519 later with a quantum computer still doesn't recover it. See docs/protocol.md.
• Transport is the Nym mixnet only: the relay never sees the client's IP.
• Federated relays for 1:1 chats: a contact can be on a different relay than yours, no relay-to-relay trust or server changes needed. See docs/adr/federated-relay.md.
• Local state (profile, contacts, message journal) encrypted at rest, XChaCha20-Poly1305.
• Small encrypted attachments (1 MB cap), fragmented and independently keyed; attachments that can't be shown inline open with the OS default app instead.
• Contact verification by safety number.
• Groups: OpenMLS (RFC 9420), create a group, add or remove members, leave a group, send and receive. Unlike 1:1, every member of a group must currently be on the same relay. See docs/adr/groups-openmls.md.

What it doesn't

No external audit. No mobile. Windows, Linux, and macOS (Intel and Apple Silicon) builds are released via CI (.github/workflows/release.yml); only the Windows one has actually been run and tested by a human. Groups are not federated (every member needs the same relay); 1:1 chats are. Post-quantum protection covers first contact only, not the whole Double Ratchet (vodozemac doesn't expose a way to inject extra key material into its root key). Full details in docs/threat-model.md.

Running it

cargo run -p desktop

The desktop app runs its own companion relay on a background thread if none is reachable, so that one command is usually all you need; there is no separate relay process to start. The relay uses a fresh ephemeral Nym identity every start (a persisted one would pin a gateway that eventually leaves the network); the app discovers its current address automatically over the relay's local HTTP endpoint.

To run a relay for others instead (see docs/operations.md):

cargo run -p relay

To run two accounts side by side for testing:

cargo run -p desktop -- --data-dir C:\tmp\telecom-alice
cargo run -p desktop -- --data-dir C:\tmp\telecom-bob

Without --data-dir, data goes in %APPDATA%\telecom.

First launch: create an account, write down the recovery phrase (a local backup secret; it does not by itself restore an account on a new device, the encrypted profile is also needed). Copy your account ID from Settings and exchange it with a contact out of band, then add them by that ID. If they use a different relay than you, also exchange and enter their relay address (leave it blank if they're on the same relay as you). The session establishes automatically once both clients can reach the relevant relays; messages queue and deliver even while the other side is offline.

Building a release

cargo build --release -p desktop

Produces target/release/TELECOM.exe, a single executable: the companion relay runs inside the app's own process, no separate binary needed next to it. cargo build --release -p relay additionally produces target/release/relay.exe, for operators who want to run a standalone relay for others rather than the desktop app's built-in one.

Verifying changes

cargo fmt --check
cargo test --workspace
cargo clippy --workspace --all-targets -- -D warnings

Layout

• crates/messenger-crypto: Olm Double Ratchet, post-quantum hybrid handshake, local storage encryption.
• crates/messenger-core: conversation state machine, attachments, message journal, local profile.
• crates/messenger-groups: OpenMLS-backed groups, isolated from the 1:1 protocol.
• crates/messenger-transport, crates/transport-nym, crates/transport-http: the Transport trait, its implementations, and RelayPool (caches a connection per relay for federation).
• crates/messenger-relay: the opaque mailbox relay.
• apps/desktop: the GUI client (egui); embeds the relay server on a background thread.
• apps/relay: the relay's server logic (used by both the standalone binary and the embedded copy in apps/desktop) and its standalone binary.
• docs/: threat model, protocol details, operations, and architecture decision records.
• .github/workflows/: CI release build, one job per platform, triggered by a version tag.