No one in the middle
Peers talk directly, via volunteer relays holding only sealed ciphertext, or over radio. There is no checkpoint where scanning can be mandated. That property comes from the architecture, not a privacy policy.
ARCHITECTURE SPEC →THE TECHNICAL VERSION · E2EE · SERVER-INDEPENDENT CORE · OFF-GRID
Komms removes the mandatory service provider from the message path. Peers communicate directly, through volunteer relays that can only see sealed ciphertext, over radio, or by carrying encrypted bundles offline.
THE ARCHITECTURE IN FOUR PRINCIPLES
Peers talk directly, via volunteer relays holding only sealed ciphertext, or over radio. There is no checkpoint where scanning can be mandated. That property comes from the architecture, not a privacy policy.
ARCHITECTURE SPEC →Hybrid post-quantum key agreement combines X25519 with ML-KEM-768. Sessions use Double Ratchet with encrypted headers and XChaCha20-Poly1305 authenticated encryption.
CRYPTOGRAPHY SPEC →The same sealed envelopes can ride local Wi-Fi, commodity Meshtastic LoRa radios, or .kkb courier files. Direct BLE and animated bundle QR are planned paths, not inflated into shipped claims.
Identity is a keypair minted on your device, not an account in a database. History is local, encrypted at rest, exportable, and deletable without asking a provider.
IDENTITY & TRUST →THE KULT MODULES · LAYERED FOR AUDITABILITY
Komms is split into narrow Rust crates with one-way dependencies. Applications can change without rewriting cryptography, and the cryptographic core can be reviewed without pulling in the UI or network stack.
Komms Ubiquitous Link Transmission
KULT-FFI
kult-node or expose secret state to an app shell.KULT-NODE
KULT-PROTOCOL
kult-crypto to perform cryptographic operations.KULT-STORE
KULT-TRANSPORT
KULT-CRYPTO
ONE MESSAGE · EVERY BOUNDARY
The app never chooses cryptography or a carrier. Each KULT module does one bounded job, and each handoff preserves enough state to survive crashes, delays, duplicates, and routes changing underneath the conversation.
Desktop, Android, or iOS calls the same typed command through kult-ffi. The shell does not receive ratchet keys, construct envelopes, or select a route.
kult-node asks kult-store to seal the outbound record first. A crash cannot turn an unsent message into fake success, and scheduled messages create no envelope before their UTC gate.
kult-protocol validates the typed content and pads it into fixed buckets. A transport never learns whether the content is text, an edit, a poll, or call control.
kult-crypto advances the per-device Double Ratchet, encrypts the header and padded content, and returns opaque ciphertext. The protocol wraps it in a sealed envelope.
kult-node ranks fresh carrier evidence and may send the same idempotent envelope over internet and mesh. Small-MTU links receive authenticated fragments; receivers safely deduplicate.
Handing bytes to a link is not delivery. The recipient persists and decrypts the message, then returns an encrypted receipt before the sender may display delivered.
Receive path: carrier → reassembly → deduplication → ratchet decrypt → sealed persistence → app event → optional encrypted receipt.
THE SEALED ENVELOPE
Link encryption is useful, but it is not load-bearing. Even a hostile carrier receives a self-protecting envelope with no plaintext conversation content or Komms identity key.
READ THE ENVELOPE SPEC →VISIBLE WITHOUT MESSAGE KEYS
The token is scoped to delivery, not a public account identifier. A v2 relay may delete at the coarse authenticated bucket; it cannot extend retention or infer the exact content deadline.
AVAILABLE ONLY AFTER AUTHENTICATED DECRYPTION
The endpoint validates the ratchet, strips padding, interprets the bounded content kind, persists it locally, and rejects unknown or malformed data without releasing plaintext.
SESSION CRYPTOGRAPHY
The design separates who a device is from the keys protecting any one message. Compromising a current key should not unlock the past, and a future ratchet step can recover security after compromise.
Ed25519 and X25519 identity material is created locally, cross-bound, and verified through fingerprints and safety numbers.
X25519 and ML-KEM-768 both contribute to the initial secret, so an attacker must break both classical and post-quantum inputs.
Root and chain keys advance per message, encrypted headers reduce metadata, and bounded skipped keys tolerate delayed off-grid delivery.
XChaCha20-Poly1305 protects padded content and associated context. Secret types zeroize when their job is finished.
TRANSPORT SCHEDULER
Every adapter reports reachability and a link profile. The node ranks latency and cost, refuses bulk airtime when only mesh is available, and treats duplicate arrival as normal.
ONE SEALED ENVELOPE, FOUR WAYS HOME
TRANSPORT ADAPTERS
.kkb files · animated QR plannedDURABLE MESSAGE PATH
Text and other asynchronous content can wait locally, use volunteer mailboxes, cross a LoRa mesh, or travel in a courier file. The delivery engine preserves truth across hours or weeks.
INTERNET · LAN · MAILBOX · LORA · FILETRANSIENT LIVE-AUDIO PATH
Ratchet-protected call control authorizes one physical device. Fresh directional keys protect bounded Opus media on /komms/call/1; no audio enters history, backup, relay, TCP, radio, or delayed work.
A serious threat model describes what the system cannot do as carefully as what it can. Komms is also pre-audit software and must not yet be treated as production-ready for high-risk use.
STATUS: 0.4.2 UNSIGNED TEST BETA PUBLISHED · STABLE GATES OPEN
GO DEEPER
The documentation contains the complete threat model, protocol design, cryptographic construction, implementation guide, and architecture decision records.
Open the documentation → Back to the simple overview