01
Your app encrypts the message locally using the Signal Protocol session.
HOW MNDO WORKS
This is the companion to the Architecture page. It explains why the system works this way before asking you to read the code.
Last updated: September 2026 · Target release: v0.4.0-beta
01 · NO CENTRAL SERVER
In a normal client-server app, one company server sits in the middle. MNDO uses Nostr relays instead: replaceable message carriers that can receive and forward encrypted events.
Centralized
Relay mesh
02 · IDENTITY
A keypair is two related keys. Your public key is like a mailbox address people can send to. Your private key is the only key that opens that mailbox.
MNDO creates this identity instantly on your device through the app's crypto layer. There is no account row to create on a server, and no phone number to verify.
Public key
Safe to share. Other people use it to find you.
Private key
Never share it. It proves the identity is yours.
03 · MESSAGE FLOW
The important part: the message is encrypted before it touches the relay network.
01
Your app encrypts the message locally using the Signal Protocol session.
02
The encrypted blob is published as a signed event to Nostr relays.
03
The recipient's app listens to those relays through NostrRelayService.
04
The message is fetched, verified, and decrypted locally on the recipient's device.
04 · SIGNAL PROTOCOL
PreKeys are public key bundles your device publishes ahead of time. They let someone start an encrypted chat with you even when you are offline.
Double Ratchet means MNDO derives a fresh message key again and again as the conversation moves. If one message key were exposed, it should not unlock old messages or future messages.
That is what people mean by forward secrecy and post-compromise security: damage is contained instead of spreading across the whole conversation history.
05 · LOCAL ENCRYPTION
End-to-end encryption protects messages while they travel. SQLCipher protects the local database where messages are stored.
At-rest encryption means the message database is not stored as readable text on disk. Even physical access to the device is not enough by itself; the attacker still needs the device's own unlock and key material.
06 · LAYERS
lib/ui/lib/providers/lib/services/lib/models/ · lib/repositories/ · lib/database/07 · GLOSSARY
A quick reference for the core cryptographic and decentralized networking concepts used across MNDO.
A mathematically linked pair of cryptographic keys: your public key (safe to share, works like an address) and your private key (secret, signs and unlocks your data).
An independent WebSocket server in the Nostr mesh that accepts, stores, and forwards signed events. Relays never see message plaintext.
A public cryptographic bundle published ahead of time so contacts can initiate an encrypted session with you even when you are offline.
An encryption algorithm that derives a brand-new secret key for every single message, preventing past or future conversations from being exposed.
A cryptographic guarantee that if a current session key were compromised, previously sent messages cannot be decrypted.
A self-healing property where the Double Ratchet automatically restores full secrecy for future messages after a temporary key compromise.
Open technical standards and protocols that define how decentralized Nostr clients and relays interoperate seamlessly.
OPEN SOURCE & COMMUNITY
MNDO is built openly under the AGPLv3 license. Whether you want to improve Nostr relay reliability, audit the cryptographic layer, or build Flutter UI features, we welcome your contributions.