PRIVACY
← Topics

The Messaging Privacy Problem

THE TRUST TRAP
Every popular messaging app requires you to trust a central server with your metadata, social graph, and message delivery. Even end-to-end encrypted apps like Signal require a phone number for identity and route all messages through Signal Foundation servers. If the server goes down or censors you, you're cut off.
NOSTR DMs TODAY
Current Nostr DMs (NIP-04) use simple ECDH encryption with no forward secrecy. If your private key is compromised, every past message is exposed. Group chats have no standard at all.
SIGNAL'S LIMITS
Phone number required. Centralized servers for delivery and key exchange. US jurisdiction. No interoperability. Group size limits. If Signal is blocked in your country, you need a VPN.
WHAT WE ACTUALLY NEED
A messaging system with no central server, no phone number identity, forward secrecy and post-compromise security for group messaging, and censorship resistance baked in at the transport layer. That's what Marmot + White Noise deliver.
Interactive Visualisation: How Marmot + White Noise Work →

Marmot: MLS Meets Nostr

TWO STANDARDS, ONE PROTOCOL
Marmot combines MLS (Messaging Layer Security, RFC 9420) — the IETF standard for efficient, secure group messaging — with Nostr's decentralized relay network as the transport layer. The result: cryptographically rigorous group encryption without any central server.
MLS
Group key
management
+
NOSTR RELAYS
Decentralized
transport
=
MARMOT
Private group
messaging
MLS: THE CRYPTO ENGINE
RFC 9420 provides a ratchet tree (TreeKEM) structure for group key agreement. Instead of pairwise key exchange between every member, keys are arranged in a binary tree. Updating a key requires only O(log n) operations instead of O(n), making groups of hundreds or thousands feasible. Every message gets forward secrecy and post-compromise security.
NOSTR: THE TRANSPORT
Nostr relays are dumb pipes — they store and forward signed events without understanding the content. Marmot publishes MLS handshake messages and encrypted payloads as Nostr events. Any relay can carry them. If one relay censors you, switch to another. No single point of failure.
KEY INSIGHT
MLS was designed assuming a central Delivery Service for message ordering and a central Authentication Service for identity. Marmot replaces both with Nostr: relays handle delivery (with multiple relays for redundancy), and Nostr keypairs handle identity — no phone numbers, no emails, no centralized PKI.

White Noise: The Implementation

White Noise (original)
First Flutter app implementing MLS + Nostr messaging. Proved the concept was viable. Now archived at whitenoise-archive.
Sloth (v3 rewrite)
Third complete rework of the Flutter app. Added multi-account support, rewrote using flutter_rust_bridge to integrate with the whitenoise-rs Rust crate.
White Noise (current)
Flutter/Dart frontend + Rust cryptographic core. Sloth rewrite renamed back to White Noise. Uses Marmot protocol with OpenMLS + Nostr. Available at whitenoise.chat.
MLS
RFC 9420 COMPLIANT
Rust
CRYPTO CORE
0
CENTRAL SERVERS
HOW IT WORKS
White Noise uses your Nostr keypair as your identity. To start a conversation, you create an MLS group and publish KeyPackage bundles to Nostr relays. Other users fetch your key packages, create Welcome messages, and the group ratchet tree is established — all through Nostr events. Messages are encrypted with the group's current epoch secret and published as Nostr events that only group members can decrypt.
MARMOT PROTOCOL LAYER
Marmot sits between MLS and Nostr, handling the translation: MLS handshake messages become signed Nostr events. It manages relay selection, message ordering guarantees, key package distribution, and group state synchronization — all the complexity that makes decentralized MLS actually work.

Why This Matters for Bitcoin

PROPERTY
SIGNAL
WHITE NOISE
Identity
Phone number
Nostr keypair
Server
Signal Foundation
Any Nostr relay
Forward secrecy
Yes (1:1)
Yes (groups too)
Group encryption
Sender keys
MLS TreeKEM
Censorship resistant
No
Yes (relay diversity)
Open protocol
Source available
Fully open
SOVEREIGNTY
Bitcoin is about removing trusted third parties. If your money doesn't need a bank, why does your messaging need a phone company and a foundation? Same keypair philosophy — you control your identity, your keys, your communication.
CENSORSHIP RESISTANCE
Coordinating Bitcoin transactions, multisig setups, or community governance requires private, reliable communication. A messaging system that can be shut down by blocking one domain is a single point of failure for everything built on top of it.
THE BIGGER PICTURE
White Noise isn't just "another chat app." It's a demonstration that MLS group encryption can work on decentralized infrastructure. The same pattern — IETF-grade cryptography on censorship-resistant transport — could be applied to any communication need in the Bitcoin ecosystem: multisig coordination, Lightning channel negotiation, coinjoin coordination, or DAO governance.
LINKS
whitenoise.chat
github.com/marmot-protocol/whitenoise (Flutter app)
github.com/marmot-protocol/whitenoise-rs (Rust core)
github.com/marmot-protocol/marmot (protocol spec)
RFC 9420 — Messaging Layer Security