Komms Protocol
Komms brings together Kaspa for trustworthy event order, Hippius for content-addressed storage, and a dedicated Bittensor subnet for indexing and semantic search. Encryption & translation stay on device — not in someone else’s cloud.
Built with
Why it matters
When one company holds identity, history, and search, communities take on custody risk, sudden rule changes, and feeds no one can audit. Komms flips the model: clear order on-chain, content and attachments off-chain with proofs, and retrieval backed by an open, incentivized network instead of a black box.
How it works
Messages and files live off-chain with cryptographic checks. Kaspa is the source of truth for what happened, in what order. A dedicated subnet indexes events, verifies storage, and powers search — with validators keeping quality honest.
1–2 The client sends encrypted content to storage and proof references to Kaspa. 3 Kaspa’s ordered events feed the subnet; the dashed line shows storage staying consistent with what miners index. 4 Validators score miner quality. 5 A bridge lets existing chat tools connect without breaking that order.
The product
The surface feels like cloud-native team software: servers, channels, threads, DMs, shared files, structured bot and agent traffic, and automatic translation in the language you read — the rhythms teams expect. Underneath, end-to-end encryption applies where the protocol defines it, with keys and decryption on your device; translation is designed the same way — local inference (WASM or OS APIs), not piping plaintext through a vendor translator. Attachments and automation pick up verifiable references, and Kaspa anchors canonical order instead of a vendor-only ledger.
What you get
Kaspa defines the order of events and who sent them. Off-chain systems can’t rewrite that history.
Each event points to content with a verifiable fingerprint — so what you fetch can be checked against what was committed.
Where end-to-end encryption applies, readable content stays with you until you choose to share it.
Subnet miners index activity, check storage, and maintain embeddings for semantic search; validators grade their work so quality matters economically.
A relay-based bridge lets existing chat platforms connect to Komms — so migration can happen in steps, not a risky big bang.
Clients get history and metadata from the subnet, but canonical order always comes from Kaspa — there’s no “only our servers can read the past” mode.
Who it’s for
Komms isn’t just another app — it’s infrastructure for communication people can trust. The same open ledger, storage proofs, and incentivized network support communities, builders, autonomous software, and partners who care about custody, clarity, and fair economics.
Servers, channels, threads, and DMs that feel familiar — with history anchored on Kaspa, message bodies and files stored off-chain with verifiable links, and search delivered by a network you can inspect instead of an opaque feed.
Clear event formats, miner APIs, validator rules, and proof-friendly flows — so teams can ship clients, indexers, bridges, and adjacent products on one shared, honest ordering layer.
Well-defined roles: index what happens on Kaspa, verify Hippius-backed content, run embeddings and search APIs, and accept validator scoring — real work for operators and aligned token economics.
Software that publishes or consumes events needs more than marketing claims: tamper-evident order, checkable content references, and retrieval APIs automation can use — without treating one company’s database as the source of truth.
Encrypt on your side so payloads stay private; publish content-addressed references and commitments on Kaspa so the same artifact can be cited and verified over time — collaborators, agents, or auditors can align on what was shared without plaintext living in a vendor vault.
A coherent story across Kaspa for order, Hippius (Bittensor SN75) for storage, and a purpose-built subnet — incentives for coordination, retrieval, and integrity instead of rent on a closed social graph.
Proof, not hype
Komms is for people who read the documentation. Event models you can implement, economics you can reason about, and client patterns proven in code already running on Kaspa — plus a public roadmap that says what’s done, what’s next, and what’s intentionally still open.
Event types, miner interfaces, validator rules, and proof-oriented flows are written for implementers — including commitments designed for efficient cryptographic proofs — not as high-level marketing bullets.
The work builds on the open-source Kasia project and the live KaChat experience on Kaspa: real-world DM cryptography, wallet flows, and a cross-platform app shell.
The roadmap records substantial MVP progress (on the order of ~60% of scoped work) and names what remains. That’s a status update for serious readers — not a delivery guarantee, and not a substitute for reading the plan.
A specified bidirectional bridge (Ferryman) connects Discord and Komms so communities can move gradually instead of abandoning tools overnight.
Private channels and group DMs use standard MLS-style group cryptography in the protocol design, with group state stored off-chain and referenced from Kaspa — not an afterthought bolted onto one-to-one chat.
A design-decision log captures dozens of resolved choices with reasoning, plus a short list of deliberate open items (such as certain storage edge cases). Less thrash revisiting basics; more focus on shipping.
Stay close
Get updates on the protocol and early access opportunities. We’ll only use your email as described in our privacy policy.
Loading form…
