PRIVACY POLICY
What data exists. Who sees it. What you control.
MNDO is built on a simple conviction: cryptographic guarantees beat policy promises. Because MNDO is decentralized, this policy explains how our architecture handles data without making false centralized claims.
The Decentralized Transparency Rule
Many messaging apps promise: “We know nothing about you” or “Click delete and all your data is gone from the universe.”In a decentralized mesh, making such claims is deceptive. MNDO uses end-to-end encryption to protect the confidentiality of your private messages, but transport metadata, public events, and relay interactions exist across independent nodes. We explain exactly what is private, what is public, and what we cannot control.
01 · INTRODUCTION
Who operates MNDO and scope of this policy
What MNDO is & Scope
MNDO is an open-source, decentralized messaging and social protocol client. It combines the Signal Protocol (Double Ratchet + X3DH) for asynchronous end-to-end encrypted private messaging with the Nostr open network for distributed event transport. This policy applies to the official web domain at mndo.online, official client distributions, and any infrastructure endpoints maintained by MNDO.
Maintainer & Domicile
MNDO is maintained independently as a public open-source project by an AISAT Computer Science student based in Kerala, India. The client code is distributed under the GNU Affero General Public License (AGPLv3). For privacy inquiries or grievance redressal, contact risvandev@gmail.com.
02 · AT A GLANCE
Data Classification & Exposure Matrix
This matrix prevents confusing 'encrypted', 'private', 'anonymous', and 'decentralized'. They are different properties.
MNDO Data Classification & Exposure Matrix
Clear cryptographic boundaries: distinguish what is encrypted, what is public, and what relays can observe.
| Data Category | Encryption Status | Publicly Visible? | Who Can Potentially Access It? |
|---|---|---|---|
Private message plaintext | E2EE (Signal Double Ratchet) | No | Conversation endpoints only |
Private message ciphertext | Encrypted payload | No (Ciphertext) | Nostr relays & network carriers |
Private media attachments | Client-side encrypted blob | No | Storage host sees only encrypted blob & hash |
Public profile (Name, bio) | None (Plain Nostr event) | Yes | Anyone querying relay events |
Public posts & reactions | None | Yes | Network peers & relay users |
Recovery phrase (12 words) | Local keystore secret | No | Local user device only; never transmitted |
Public key / Identifier | No secrecy intended | Yes | Publicly discoverable across the mesh |
Relay & network metadata | Transport-level | Relay-visible | Independent relay operators (IP, timing, frequency) |
03 · DATA CATEGORIES
Detailed breakdown of data we process
Data is processed across four distinct technical domains: identity credentials, private communications, public social events, and network metadata.
1. Identity & Profile Data
- •Cryptographic Public Key: Your
npub/ Ed25519 identity key used to discover and route messages. - •Display Name & Bio: Optional user metadata published as a Nostr kind:0 metadata event.
- •Profile Avatar: Optional HTTPS or Blossom URL referencing an image.
- •12-Word Recovery Phrase: Generated and stored strictly in your device's hardware-backed keystore. Never transmitted to MNDO infrastructure. You hold custody; we cannot recover it.
2. Private Communication Data
- •Ciphertext Payloads: Messages are encrypted on your device prior to transmission via Signal Double Ratchet.
- •Encrypted Media Descriptors: Voice notes and attachments are locally encrypted with AES-256 before upload. Keys are sent inside the E2EE envelope.
- •Local Session State: Ratchet keys, PreKeys, and chat transcripts are stored in encrypted SQLite (SQLCipher) on your device.
- •Sync Metadata: Timestamps, message IDs, and delivery receipts are relayed through transport events. We do not claim zero metadata.
3. Public Social Data
- •Public Posts & Replies: Signed Nostr kind:1 text events intended for public distribution across the network.
- •Public Reactions & Reposts: Explicit public engagement events broadcast openly without end-to-end encryption.
- •Contact Lists & Relays: Your chosen list of relays and followed public keys (NIP-02/NIP-65).
4. Technical & Network Metadata
- •IP Address & Network Telemetry: Whenever your client connects via WebSocket to a Nostr relay, the relay operator observes your IP address and connection timing.
- •Event Timestamps & Kinds: Publication timestamps (
created_at) and event kinds are visible to relay routers. - •Publication Frequency: Traffic analysis can observe when you publish events, even when content ciphertext is opaque.
04 · DATA MINIMISATION
What we do not intentionally collect
We only state what is genuinely true for our architecture, without hand-waving.
No Central Accounts
We do not maintain a central user database, username registry, or password hash repository.
No Phone or Email Required
Core identity creation requires zero phone numbers, email addresses, or government IDs.
No Private Keys Received
We never receive, log, or hold your 12-word seed phrase or private identity keys on any server.
No Plaintext Message Snooping
No MNDO-operated server receives or stores the plaintext of your private Signal-ratcheted messages.
05 · PURPOSE LIMITATION
Why data is processed (DPDP Framework)
In compliance with India's Digital Personal Data Protection (DPDP) Act 2023 and the notified 2025 Rules, data processing is strictly bound to lawful, specified purposes.
1. Cryptographic Identity
Generating and maintaining keypairs, signing events, and verifying cryptographic signatures across the peer mesh.
2. Message Routing & Delivery
Broadcasting encrypted envelopes to configured Nostr relays so recipient devices can retrieve and decrypt them asynchronously.
3. User Discovery (Optional)
Resolving public keys and peer contact cards when you explicitly search or follow someone on the open network.
4. Encrypted Media Delivery
Uploading and downloading client-side encrypted media blobs to distributed Blossom storage servers.
5. Service Integrity & Security
Preventing relay flooding, replay attacks, duplicate message processing, and securing client application stability.
6. Legal & Regulatory Compliance
Complying with valid legal processes and statutory mandates under applicable laws of India where technically applicable.
06 · DECENTRALIZED INFRASTRUCTURE
Independent relays and third-party nodes
MNDO does not run a monolithic closed cloud. Messages and events travel over Nostr relays and Blossom media servers operated by independent individuals and organizations worldwide.
07 · METADATA REALITY
Why MNDO is not 'completely anonymous'
End-to-end encryption protects the confidentiality of message content, but encryption is not anonymity. Anyone inspecting relay traffic or operating a relay you connect to can potentially observe:
- • Your public key (
npub) - • Recipient public key tags on envelopes
- • Connecting IP address & ISP telemetry
- • Event timestamps and publication frequency
- • Nostr event kinds and payload sizes
- • Public social interaction graphs
To mitigate network metadata exposure, users may route relay WebSocket traffic through Tor or VPNs on supported platforms.
08 · PUBLIC CONTENT
Public posts cannot be recalled from the world
The Immutability of Public Nostr Events
When you publish a public post, status, or reply in MNDO, it is cryptographically signed with your key and broadcast to public Nostr relays. Third parties, archiving bots, and relay operators can mirror, index, and cache these events indefinitely.
Deleting a post inside your local MNDO app sends a deletion request event (NIP-09), but compliance depends entirely on each independent relay. We cannot guarantee that third-party relays will delete cached copies. Do not publish anything publicly that you require to remain confidential.
09 · RETENTION & DELETION
What happens when you delete data
Local Device Data
Stored in encrypted SQLite (SQLCipher) and secure hardware keystore. You have complete control: clearing app data or uninstalling the app permanently deletes local message records, private keys, and session ratchets from the device.
MNDO-Operated Servers
If connecting to official MNDO relay or discovery instances, ephemeral event caches and routing tables are retained only as long as necessary for delivery, with automated expiry cycles (typically 7 to 30 days for ephemeral message envelopes).
Independent Relays
Retention on third-party relays is dictated by the relay operator's policies. Even though private message payloads are unintelligible ciphertext, the encrypted envelope may remain stored on third-party relay disks until purged by the operator.
10 · YOUR RIGHTS
Data Principal Rights under the DPDP Act
In accordance with the Digital Personal Data Protection Act, 2023, MNDO provides mechanisms for users to exercise their rights regarding personal data.
Right to Access
You can export your local message database, keys, and settings directly from the MNDO client application at any time.
Right to Correction & Updating
You can update your profile metadata, display name, bio, and relay preferences whenever you wish by publishing updated events.
Right to Erasure
You can wipe all local client storage instantly. For MNDO-controlled servers, you may submit an erasure request to our Grievance Officer.
Grievance Redressal
If you have questions, concerns, or grievances regarding your data, contact our designated Grievance Officer at risvandev@gmail.com.
11 · CHILDREN'S PRIVACY
Age limits and child data safeguards
MNDO is not directed to children under the age of 13 (or under 18 where applicable without parental consent under the DPDP Act). We do not knowingly solicit or collect personal information from minors. Because MNDO does not use centralized accounts, age verification is not enforced via server-side identity tracking. If you believe a minor is using MNDO in violation of applicable laws, please contact our grievance address.
12 · THIRD PARTIES
External services MNDO interacts with
MNDO relies only on the minimal external services required to function as an open decentralized client.
| Service Type | Purpose | Data Handled |
|---|---|---|
| Nostr Relays (Public / User-Selected) | Message envelope transport & public event distribution | Signed events, public keys, timestamps, connecting IP addresses |
| Blossom Media Servers | Decentralized storage of encrypted media blobs | Opaque encrypted binary blobs, SHA256 hashes, HTTP request logs |
| UnifiedPush / Push Gateways | Optional background message wake notifications | Device push registration token, encrypted wake payload |
| GitHub Releases | App distribution, bug reporting, source code hosting | Public GitHub profile info when submitting issues or PRs |
13 · INTERNATIONAL TRANSFERS
Decentralized cross-border data flows
By nature of decentralized protocols, Nostr relays and Blossom media hosts are distributed across multiple nations and jurisdictions. When you connect to international relays, your encrypted events and connection metadata may cross international borders. MNDO does not transfer personal data outside India other than as initiated directly by your client connecting to the peer-to-peer relay network you configure.
14 · INCIDENT HANDLING
Privacy & security incident notification
In the event of a security or personal data breach affecting MNDO-controlled systems, we will take immediate remedial actions and notify the Data Protection Board of India (DPBI) and affected individuals without delay, in compliance with the DPDP Rules and Indian Computer Emergency Response Team (CERT-In) guidelines.
Policy Changes & Inquiries
We may update this Privacy Policy periodically. Substantial changes will be announced in release notes and through our open GitHub repository. All revisions are committed transparently to public version control.