The year 2023 closed with a revelation that should have caused greater alarm than it did. A U.S. Senate investigation disclosed that governments, both foreign and domestic, had been quietly demanding push notification records from Apple and Google. These requests, previously hidden under gag orders, allowed authorities to link anonymous users of messaging applications to specific Apple IDs and Google accounts.
This was not some exotic zero-day vulnerability. It was an architectural feature of how mobile devices work. Every iPhone and Android phone maintains a persistent connection to Apple's Push Notification Service or Google's Firebase Cloud Messaging. When Signal sends you a notification that a new message has arrived, that notification routes through these company servers.
For users who believed that end-to-end encryption protected their communications, this represented a rude awakening. Your messages might be mathematically secure, but the fact that you received a message at 2:47 AM from an application associated with political organizing was logged and available to anyone with a subpoena.
Apple and Google will always know that your device received a notification for a particular app. That is unavoidable. But the app developer's notification server represents a separate point of exposure. Most implementations store device tokens persistently and can identify exactly which users received notifications and when. This database is subpoena-able, hackable, and in some cases voluntarily shared.
The Marmot Protocol team focused on this second problem. MIP-05, drafted in November 2025 and currently under review, ensures that the notification server itself learns nothing about which users are communicating.
The Notification Pipeline Problem
Many messaging applications send push notifications in cleartext. When you receive a notification that says "Alice: Are we still meeting at 3pm?", that exact text traveled through the app developer's server and through Apple or Google's infrastructure before reaching your lock screen. Both the developer and the platform provider can read it. End-to-end encryption of message content means nothing if the notification itself contains the message.
The architecture makes this unavoidable. When you install a messaging application, the app registers with the platform's push service and receives a device token tied to your Apple ID or Google account. This token is useless on its own. To send you a notification, someone must have access to platform credentials, which Apple and Google grant only to registered app developers. The developer must therefore run a server that receives notification requests from sending users, holds the platform credentials, and forwards notifications to Apple or Google, which then wake up your device.
Both the developer's server and the platform provider log metadata about every notification: which app, which device, which account, and when. If the developer stores tokens persistently, that database becomes another target for legal demands.
For Marmot, which combines the MLS Protocol with Nostr's decentralized relay network, this creates a problem. The messages themselves have forward secrecy and post-compromise security. But the notification layer requires centralized infrastructure that reveals communication patterns and, for many apps, reveals the content itself.
How MIP-05 Removes Trust
The notification server is unavoidable. Apple and Google require it. MIP-05 accepts this constraint but removes the need to trust that server with anything beyond uptime. Three mechanisms accomplish this.
First, device tokens are encrypted with probabilistic encryption before any distribution. Each time a device encrypts its push token, it generates a fresh ephemeral keypair. Using Elliptic Curve Diffie-Hellman key agreement against the notification server's public key, the device derives an encryption key via HKDF, then encrypts with ChaCha20-Poly1305. The same device token, encrypted twice, produces completely different ciphertexts. The notification server cannot correlate tokens across events or link them to specific users. All tokens are padded to exactly 280 bytes, preventing inference of the user's platform from ciphertext length.
Second, the server operates statelessly. It decrypts tokens on the fly, forwards silent notifications to Apple or Google, and discards everything. There is no persistent database to subpoena. The notifications themselves contain no content, only a wake-up signal. The app then fetches actual messages from the Nostr relay network and decrypts them locally.
Third, senders communicate with the notification server through gift-wrapped Nostr events. A notification trigger is sealed with an ephemeral key, then wrapped again with a separate outer ephemeral key per NIP-59. The server receives a stream of anonymous requests with no way to identify senders or correlate successive events.
Token Distribution via Gossip
Encrypted tokens must reach all group members so anyone sending a message can trigger notifications for recipients. MIP-05 specifies a gossip protocol using three event kinds within MLS application messages.
When a device joins a group, it broadcasts a kind 447 token request containing its own encrypted token. Members respond with kind 448 events containing their complete view of all tokens in the group. Kind 449 events signal token removal. Multiple members can respond to any request, ensuring delivery even when some participants are offline. The protocol converges naturally as members observe and merge updates.
The inner events remain unsigned. If messages are ever leaked, they cannot simply be copy-pasted and published to Nostr relays, which reject unsigned events. Authentication comes from the MLS layer.
Decoy Tokens
A sophisticated observer might attempt to infer group sizes by counting tokens in notification events. MIP-05 addresses this by including decoy tokens: randomly generated 280-byte values indistinguishable from legitimate encrypted tokens.
Senders add decoys representing 10-20% of the real token count, with a minimum of three per event. When the notification server attempts to decrypt a decoy, the operation fails silently. The server ignores invalid tokens and processes only legitimate ones. An adversary monitoring incoming events cannot reliably determine actual group sizes.
What Each Party Learns
The notification server learns the timing of events and an upper bound on recipient counts, obscured by decoys. It cannot determine message content, sender identity, or which tokens belong to which users.
Apple and Google learn that a notification was delivered to a specific device. They know the device owner's platform identity. They cannot determine message content, sender identity, recipient Nostr identity, or group membership.
Group members learn which MLS leaves have registered tokens and which notification servers are in use. They cannot see actual device tokens, which are encrypted to the notification server.
Constraints
The specification imposes strict requirements. Clients must use native platform tokens. Routing iOS notifications through FCM would expose iOS users to Google in addition to Apple, so this is forbidden. Each token encryption must use fresh ephemeral keys. Optional enhancements include routing notification events through Tor for IP-level anonymity.
Conclusion
Privacy in networked systems requires examining every layer of the stack. End-to-end encryption at the message layer means nothing if metadata at the notification layer reveals what governments would have extracted from plaintext. Privacy-conscious apps already send blank notifications, but their servers still know which users receive them. MIP-05 goes further, ensuring the notification server learns nothing at all. For users in authoritarian regimes, for journalists protecting sources, for anyone whose communication patterns constitute sensitive information, this specification matters.
Governments understood something that many privacy advocates overlooked: sometimes the metadata is more valuable than the message itself. MIP-05 ensures that even metadata reveals nothing worth knowing.