CraysWhite Noise
White Noise is not trying to be another social client with a DM drawer bolted on. It is a private messenger first, built around Nostr keys, Marmot group encryption, Blossom media and the refusal to make your phone number the price of admission.
Chat without the border crossing
Most private messengers begin with a checkpoint. Give the app your phone number. Prove an email. Let a company hold the social graph. Then, once the account has been made, you may get encryption. White Noise starts from a different instinct: your key is enough. The public Nostr profile says the quiet part plainly: chat with no phone number and no central server to shut down.
That is the emotional hook of the app. White Noise is not a place to post into a public feed. It is a place to talk to people. Direct conversations, group conversations, media, message search, blocked users, archived chats, markdown rendering, push notifications, and multiple identities all sit around that one job. If you have watched Nostr clients treat DMs as an awkward extra tab, White Noise feels like a correction. It says: private chat is not a side quest.
The interesting thing is that White Noise does not simply paste an old messenger shape on top of Nostr. A phone-number messenger can be excellent and still have a narrow throat: one company controls the account registry, the notification path, much of the abuse response, and often the backup story. White Noise tries to move those pieces outward. Identity comes from keypairs. Relays move events. Blossom servers hold media. The Marmot layer handles group encryption. The app becomes an interface to a protocol system, not the owner of the room.
That choice gives the product its strange mix of ambition and friction. You gain an identity that can exist beyond one app. You lose some of the tidy guarantees of a single platform. You can pick relays and signer setups. You also need to understand that a relay is not a magical privacy fog. It can move encrypted events without reading your messages, but it still participates in delivery. White Noise is best read as a serious attempt to make that trade feel usable.
The official site now presents the project in unusually direct language for Nostr: private messaging, no phone or email requirement, open and decentralized, built on Nostr, Blossom and MLS through Marmot. It also frames the project as non-profit and community-driven, supported by OpenSats, the Human Rights Foundation and And Other Stuff. That matters because the app is entering a category where trust is not decorative. A private messenger has to explain itself.
Marmot is the protocol under the app
The word you need for White Noise is Marmot. The app is the visible client. Marmot is the protocol machinery underneath it. The project describes Marmot as a way to combine Nostr, MLS and Blossom for decentralized encrypted messaging. In plain English: Nostr gives you keys and relays, MLS gives group encryption with key updates, and Blossom gives a way to store and fetch media without pretending that every image belongs inside a tiny relay event.
This is why White Noise should not be judged like a simple NIP-04 or NIP-17 DM client. Those older patterns are useful pieces of Nostr history, but Marmot is built for a harder problem: group messaging that can survive membership changes, multiple devices, async invites, attachments, and notification routing. The Marmot repository is explicit that the protocol is about efficient end-to-end encrypted group messaging using Nostr's identity and relay network together with MLS.
The developer-facing route is the MDK, the Marmot Development Kit. The build docs describe it as a modular Rust SDK that needs Rust 1.90.0 or newer and SQLite. The crate layout is practical rather than vague: an `mdk-core` library for MLS, Nostr integration and group management, storage traits for custom backends, in-memory storage for development, and SQLite storage for production use with encryption.
The event model is also public. Marmot clients publish key packages, welcomes, encrypted group events, push token requests and relay-list events. Kind 443 is the public key package used for async group joins. Kind 444 carries the welcome sent to a new member and is wrapped with NIP-59. Kind 445 carries encrypted group traffic. Kinds 447, 448 and 449 handle push notification token exchange. Kinds 10050 and 10051 tell clients where notification and key-package relay data should live.
That kind of detail is useful for a reader because it keeps the app honest. White Noise is not just saying "private" and asking you to clap. It is publishing the shape of the system. You can see where group setup happens, where message traffic goes, where notification support enters, and where the protocol is still marked as young. The build page says the project is in beta and its protocol specifications are in review status. That is not a weakness to hide. It is the correct warning label for software that touches private communication.
Why MLS changes the group chat story
Messaging Layer Security, or MLS, is the technical reason White Noise can talk seriously about private groups. One-to-one encryption is hard enough, but group encryption is where chat apps start to show their bones. People join. People leave. Devices are replaced. A phone is stolen. Someone comes back from an old backup. The app has to keep the room moving without letting yesterday's key read tomorrow's conversation.
MLS was designed for this exact mess. White Noise's privacy policy explains it as an IETF standard for end-to-end encrypted group messaging with forward secrecy and post-compromise security. Forward secrecy means a stolen current key should not expose old messages. Post-compromise security means the system can rotate away from damage after a compromise instead of living forever under one bad secret.
Marmot's build docs name the default ciphersuite: `MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519`. You do not need to memorize that to use the app, but it tells you the stack is concrete: X25519 for key exchange, AES-128-GCM for encryption, SHA-256 for hashing and Ed25519 for signatures. The important architectural move is identity separation. Nostr keypairs identify you, but MLS signing keys are separate, and each device is its own MLS leaf. In a private messenger, that separation is not academic. It limits what a compromised Nostr identity can reveal about group messages.
White Noise turns those ideas into product behavior. The GitHub README lists encrypted group messaging, keypair identity, external signer support, media, search, block and mute controls, chat archiving, multi-account use, encrypted local storage and automatic database migrations. That is the list you want to see in a real messenger. The encryption story matters, but so does the ordinary day-to-day work of finding a message, leaving an old chat alone, or using a second identity without mixing everything together.
The project also names its limits. Marmot currently says welcome messages can exceed relay size limits above roughly 150 group members, and that work is underway on a lighter welcome path. That is exactly the sort of sentence that makes a protocol page more trustworthy. It tells you where the edge is. If your use case is a small team, a family, a project group or a private community, White Noise is pointed straight at you. If you want a giant public chat with thousands of people, you should test before assuming the system is ready.
Relays, Blossom and push are still part of the deal
White Noise is private, but it is not invisible. That distinction is the difference between good security writing and fantasy. The privacy policy says the app runs locally on your device, private keys never leave the device, and encryption and decryption happen on-device. It also says the app communicates with Nostr relays, Blossom servers and, if you enable notifications, Transponder push infrastructure.
Relays carry encrypted Nostr events. According to the policy, White Noise ships with default relays, but you can add, remove or replace them. IPF says it does not operate Nostr relays. A relay operator may observe your IP address and the encrypted events you publish or retrieve, while the message content remains unreadable to that operator. Group message events are published with ephemeral Nostr keypairs rather than your identity keypair, which reduces the metadata a relay can connect to your main public key.
Blossom handles media such as images and attachments. Here again, the honest version is better than the marketing version. Public profile media is public because it is meant to be public. Media shared inside encrypted group conversations is encrypted before upload, so a Blossom server should see ciphertext rather than the image itself. But the server can still observe that you uploaded or retrieved data, and your relay and media choices still matter.
Push notifications are the awkward part of every private messenger. People want instant messages, but mobile operating systems route notifications through Apple and Google. White Noise uses a notification service called Transponder when push is enabled. The privacy policy says notification events are encrypted, notification requests use ephemeral Nostr keypairs, and IPF can decrypt the device token needed for delivery without reading notification content. The Transponder README describes a Rust MIP-05 server that subscribes to NIP-59 gift-wrapped notification requests and dispatches silent APNs and FCM pushes. A White Noise post from May 22, 2026 says iOS push notifications are live and that the iOS Notification Service Extension decrypts the payload on the device so Apple sees delivery, not the message, sender or identity.
This is the part a careful reader should appreciate. White Noise is not promising that no infrastructure exists. It is trying to minimize what each piece can know. Relays move encrypted events. Blossom stores encrypted group media. Push infrastructure wakes the phone without reading the message. Local storage is encrypted on device. The system has moving parts, but the parts are designed so no single one has to become the old central account server in disguise.
What the app can actually do now
The public app repository calls White Noise a private, decentralized messenger built on Nostr using Marmot for MLS group encryption. As of the current repository state, Android and iOS are supported. macOS, Windows, Linux and web are listed as planned. The app itself is Flutter, the core is Rust through `whitenoise-rs`, the bridge is `flutter_rust_bridge`, and the protocol is Marmot. The repository is AGPL-3.0, which matters because a messenger that asks for trust should also invite inspection.
Feature-wise, White Noise is already more than a proof-of-concept chat box. It supports keypair accounts created in the app or imported by the user. It works with Amber and other NIP-55 Android signers, which means your private key can stay outside the app entirely if that is how you prefer to work. It supports encrypted group messaging, media with loading previews, conversation search across groups, blocking, muting, archiving, multiple accounts, encrypted local storage and database migrations.
The distribution story is still beta-shaped, and that is useful to know before you send family or colleagues there. The official download page points iOS users to TestFlight, Android users to Zapstore, and Android power users to direct GitHub APK releases. That is not the posture of a polished mass-market messenger yet. It is the posture of a serious open-source project moving quickly while keeping release artifacts, checksums and changelogs in public view.
The release trail gives useful texture. The White Noise Nostr profile announced version 2026.5.22 on May 22, 2026 with iOS push notifications, markdown message rendering, a blocked users screen, deep links for chats and profiles, and Simplified and Traditional Chinese support. A March post mentions faster message arrival, stable group chats, better image sharing, Amber support and the key phrase "keys only, no phone number." Those are not abstract promises. They show the project moving through the small hard things that make a messenger feel real.
You can also see the app's priorities in what it does not use as an identity anchor. No phone number. No email. No traditional account recovery desk. That is freeing, but it also places responsibility back on you. If you lose the key material and local state you need, IPF says it cannot recover your private key. For some readers, that will feel like a relief. For others, it will feel like danger. Both reactions are reasonable. Self-custody of identity always has teeth.
There is a TypeScript implementation called `marmot-ts`, but the build docs describe it as early-stage and not feature-complete. That is worth saying because people often assume Nostr tools are instantly web-first. White Noise is currently more mobile-native: Flutter UI, Rust core, Android and iOS support, and a roadmap toward desktop and web. If your life is all browser tabs, keep that in mind. If your private chat life is mostly phone-based, the current shape makes more sense.
Who is behind White Noise
The public policy and site identify Internet Privacy Foundation, or IPF, as the organization behind the service. The privacy policy says IPF is a Wyoming nonprofit corporation and acts as data controller for information processed through IPF-controlled infrastructure. The official site describes White Noise as non-profit and community-driven, not funded by a corporation and not beholden to a government or organization.
The human trail begins before IPF. White Noise's own year-in-review says Jeff Gardner and Max Hillebrand compared OTR, Signal-style Double Ratchet work and MLS through 2024 before converging on Marmot. Gardner is described in the project's interview material as White Noise's founder, while Hillebrand appears throughout the public writing as a key protocol and privacy voice. The project then gathered contributors around the Rust core, the Flutter app, the MDK, design, translations and release work. The May 2026 release notes name Jeff Gardner, Pepi, Danny Morabito, Mubarak Auwal, Javier Montoya, stupidloud and Datawav as contributors for that release.
The open-source trail sits under the `marmot-protocol` GitHub organization. There is the White Noise Flutter app, the Marmot protocol specification, the MDK, `whitenoise-rs`, Transponder, `marmot-ts`, and related experiments. The app repository lists Flutter, Rust, `flutter_rust_bridge`, Marmot, Android and iOS support, AGPL licensing, releases and contribution guidance. The Marmot and MDK repositories are MIT licensed, while the app and Rust backend are AGPL-3.0.
The security posture is more interesting than a simple yes-or-no audit label. Least Authority has published a Marmot Protocol Review summary for White Noise, and the project blogs say audit feedback has already driven SDK and app fixes. The report's recommendations are exactly the kind a careful reader should want to see in public: define a more explicit threat model, tighten dependency requirements, keep key compartments separate, specify admin behavior, and improve encrypted media nonce handling. That mix is important. White Noise is public enough to inspect, but young enough to demand caution. Read the repo. Read the privacy policy. Look at the release history. Notice the beta warnings. Then decide whether the project's threat model matches your own conversations.
The project's Nostr account is also part of the product. It publishes updates, release notes, privacy arguments and links back to the app and GitHub. That is useful in Nostr culture because a project account is more than a marketing channel. It is a living public key you can follow, inspect and cite. For White Noise, that profile reinforces the central promise: the app wants chat to be tied to keys, not phone-number identity.
How to test White Noise like a grown-up
Start with the identity path. Create a fresh test key or use a signer setup you understand. If you are on Android and you already trust Amber, try White Noise with external signing so the private key stays out of the app. If you import or create a key directly, know where it lives, how it is backed up, and what you are comfortable losing. Do not make your first experiment a chat whose history would hurt someone if your own device is messy.
Then test the messenger as a messenger. Create a one-to-one chat and a small group. Send plain text, markdown, an image, and a short video if the app allows it on your platform. Search for an older message. Mute someone. Block someone. Archive a chat. Switch accounts if you use multiple identities. Leave the app, come back, and check whether the local encrypted state feels dependable.
After that, test the protocol edges. Add and remove a group member. Try a second device if your setup allows it. Watch how long a welcome takes. Check whether everyone sees the same group state. If a relay is down, see whether the conversation recovers when another relay is available. This is where the Marmot promise either becomes boring in the best way or shows you where beta software still needs time.
Test media and notifications with your eyes open. Media in encrypted groups should be encrypted before Blossom upload, but Blossom operators may still see network-level interaction. Push should not reveal message content, but mobile push systems always deserve scrutiny. If you have a high-risk use case, test with your own relays, your own Blossom choices, and notification settings that match your risk instead of your convenience.
Finally, test the social reality. Can the people you actually want to message install it, understand keys, and stay in the chat without you becoming their support desk? A private protocol can be beautiful and still fail at the kitchen-table level. White Noise is exciting because it is trying to make the serious architecture feel like ordinary chat. The only honest test is whether that works for the people in your room.
White Noise sources worth opening
White Noise has unusually useful public sources. Read them in this order if you want to understand the app before trusting it with private conversations.
- White Noise official project page
- White Noise downloads
- Build with Marmot
- White Noise privacy policy
- White Noise blog index
- White Noise contribution page
- White Noise warrant canary
- White Noise v2026.5.22 release post
- Marmot Protocol April 2026 recap
- Marmot Protocol March 2026 recap
- Interview with White Noise founder Jeff Gardner
- White Noise and Marmot 2024-2025 year in review
- White Noise GitHub repository
- White Noise GitHub releases
- White Noise app README
- White Noise Flutter dependency manifest
- White Noise AGPL license
- Marmot protocol specification
- Marmot MIP-00 credentials and KeyPackages
- Marmot MIP-01 group construction
- Marmot MIP-02 welcome events
- Marmot MIP-03 group messages
- Marmot MIP-04 encrypted media
- Marmot MIP-05 push notifications
- whitenoise-rs core and CLI
- whitenoise-rs README
- whitenoise-rs Cargo manifest
- Marmot Development Kit
- MDK README
- MDK Cargo manifest
- marmot-ts README
- Transponder MIP-05 push server
- Least Authority Marmot Protocol Review summary
- White Noise Nostr profile
- White Noise Zapstore listing
- RFC 9420 Messaging Layer Security
- NIP-04 encrypted direct message legacy context
- NIP-17 private direct messages context
- NIP-44 versioned encryption
- NIP-59 gift wrap
- NIP-55 Android signers
- Blossom media storage
- OpenMLS Rust implementation
- rust-nostr protocol library
- flutter_rust_bridge
- Flutter documentation
