Know Your Enemy, Name Your Defenses

Security is a relationship, not a property. It exists between three things: the asset you are protecting, the adversary you are protecting it from, and the resources that adversary can bring to bear. A bank vault that defeats a lone burglar may crumble before a state intelligence agency. A disguise that fools your neighbors fails against facial recognition. Any security claim that omits any of those three elements is poetry, not analysis.

Threat models exist for this reason. A threat model names your enemies and describes what they can do. It forces engineers to be precise about what they are building and for whom. It forces users to ask whether a product addresses their situation. Without a threat model, security discussions devolve into vague reassurances and marketing slogans.

The Marmot Protocol, a specification for encrypted group messaging built on Nostr's decentralized network, publishes exactly such a document. It enumerates what the protocol defends against, what it does not defend against, and why. This choice separates engineering from theater.

The adversaries Marmot fights

The Marmot threat model specifies four categories of adversaries the protocol is designed to defeat, and for each one, it deploys specific countermeasures.

First, passive relay operators. Nostr relays are the servers that store and forward encrypted messages. Unlike centralized messengers, Nostr relays can be run by anyone, which means relay operators may be unknown and untrustworthy. Marmot assumes relay operators will attempt to surveil communications. The defense is layered. Message contents are encrypted using MLS's authenticated encryption with associated data, specifically AES-128-GCM, which provides both confidentiality and integrity. But content encryption alone would still leak sender identity through Nostr's standard event signatures. Marmot defeats this by using fresh ephemeral keypairs for every message. Each group message is signed with a disposable key that is used exactly once and then discarded. Relay operators see encrypted ciphertext, group identifiers as SHA-256 hashes (irreversible to group names), timestamps, and ephemeral public keys that are unlinkable across messages. Message content, sender identity, recipient identity, and group membership all remain opaque. The social graph remains invisible.

Second, active relay operators who interfere with message delivery. A malicious relay might drop messages, delay them, reorder them, or replay old messages in an attempt to confuse or compromise group state. This is a serious threat because MLS group state depends on members processing messages in a consistent order. Marmot handles this through deterministic commit ordering rules. When two conflicting state changes arrive for the same epoch, clients resolve them by selecting the commit with the lowest timestamp. If timestamps match, they use the lexicographically smallest event identifier. This deterministic tiebreaker means all honest clients converge to the same group state without requiring a trusted coordinator. Message replay is defeated by MLS's epoch and generation counters: each message includes identifiers that prevent an old message from being accepted twice. Message dropping is handled at the application layer through acknowledgment schemes, and clients can query multiple relays for redundancy.

Third, compromised group members from previous epochs. This is forward secrecy in practice, and Marmot inherits it from MLS's TreeKEM construction. The mechanism works as follows: each epoch of the group derives its encryption keys from the previous epoch's secrets using one-way cryptographic functions, specifically HKDF with SHA-256. When a member sends a message, they use a key derived from the current epoch's secret. After sending, they delete the key material used for previous epochs. If an attacker compromises a member's device today and extracts the current epoch keys, the one-way cryptographic functions block recovery of keys from earlier epochs. Those messages remain encrypted with keys that no longer exist anywhere. The attacker can read current messages, but the past is cryptographically sealed.

Fourth, state-level network surveillance. Assuming users employ VPN or Tor to mask their IP addresses, network observers see only encrypted traffic flows to public Nostr relays. Who communicates with whom, which groups exist, and what is being discussed all remain hidden from them. The decentralized architecture means no single server observes the sender, recipient, and timestamp of every message. Metadata remains distributed across whatever relays each user chooses. The ephemeral keypairs provide an additional layer: even if an observer correlates traffic to a specific relay, ephemeral keys make messages unlinkable to persistent identities.

What Marmot cannot save you from

Here is where the threat model earns its credibility. Marmot explicitly acknowledges four classes of attacks outside its defensive scope.

Compromised end-user devices. If malware controls your phone, it reads your messages after decryption. No cryptographic protocol survives the adversary already being inside the castle. Every cryptographic protocol shares this limitation. The protocol protects messages in transit and at rest on relays. The device holder has full access after decryption.

Traffic correlation attacks by colluding relays. If multiple relay operators share information, they might link users by timing patterns alone, regardless of encryption. Alice connects to Relay A at 3:47 PM. Bob connects to Relay B at 3:47 PM. Both relays report activity in the same encrypted group. A sophisticated adversary might infer they are communicating. Marmot's ephemeral keys raise the difficulty substantially, though the attack remains theoretically viable.

Quantum computers breaking elliptic curve cryptography. The X25519 key exchange and Ed25519 signatures that underpin Marmot's current implementation will fall to sufficiently powerful quantum computers. The protocol's architecture supports future migration to post-quantum ciphersuites like X-Wing, but deployment at scale is still pending. For now, the threat is theoretical and distant.

Coercion to reveal keys. Cryptography yields to someone holding a wrench to your kneecap. Marmot's forward secrecy means coerced key disclosure reveals only current and future messages, not past ones, but this is cold comfort to someone facing state-sponsored interrogation. The protocol makes no promises about rubber hose cryptanalysis.

Why this honesty matters

The Marmot threat model matters because it tells you whether the protocol solves your actual problem.

Are you a journalist protecting sources from corporate surveillance? Marmot's metadata protection and decentralized architecture address your threat model directly. No single server operator can be compelled to produce communication records, because no single server has them.

Are you an activist organizing against a state with nation-state surveillance capabilities and a willingness to detain and torture? Marmot helps, but it is not sufficient. You need operational security beyond the protocol itself: air-gapped devices, physical security practices, compartmentalized communication networks. A compromised device or coerced member defeats the protocol.

An explicit threat model lets you make informed decisions on sound premises.

The architectural foundation

Marmot achieves its security properties by combining the MLS protocol, standardized by the IETF as RFC 9420, with Nostr's decentralized relay network. MLS provides the cryptographic machinery: TreeKEM for efficient group key management, automatic key rotation for forward secrecy and post-compromise security, and authenticated encryption for message confidentiality. But MLS deliberately leaves two critical components out of scope: the Delivery Service that routes messages between participants, and the Authentication Service that binds cryptographic keys to human identities.

Nostr fills both gaps. As a Delivery Service, Nostr's network of independent relays stores and forwards encrypted events with trust spread across independent operators, eliminating single points of failure. As an Authentication Service, Nostr enables users to declare their own identity. Users control their own keypairs, choose their own usernames, and publish their own MLS KeyPackages to relays they select. There is no central authority issuing credentials or vouching for identity claims. You are your key. Other users verify you through whatever out-of-band methods they choose, whether that means checking a website, a social media profile, or a face-to-face exchange of public keys.

This combination addresses weaknesses in both component technologies. MLS alone requires some delivery service to route messages, traditionally a central server that creates a surveillance chokepoint. Nostr alone provides only basic encryption without forward secrecy, post-compromise security, or efficient group messaging. Together, they enable something neither achieves independently: decentralized secure group communication that scales to thousands of members without trusting any infrastructure operator.

Secure messaging tradeoffs

Different messaging systems make different tradeoffs, and those tradeoffs matter for different threat models.

Signal offers excellent cryptography, careful implementation, and polished user experience. Its tradeoffs are architectural: phone number registration ties identity to telecommunications infrastructure, its servers observe communication metadata even when contents remain encrypted, and its operation depends on a single nonprofit organization. These are reasonable choices for Signal's mission, which prioritizes mainstream adoption and usability.

Nostr's existing direct message implementations, using NIP-04 and NIP-17, provide decentralization without the cryptographic sophistication of modern group messaging protocols. They lack forward secrecy and struggle with group conversations at scale.

Marmot occupies a different point in the design space. The specification is under active development and may introduce breaking changes, but Marmot and MDK, its reference implementation, are currently undergoing a formal security audit. This represents a coherent answer to a specific question: what does secure group messaging look like when infrastructure operators are adversaries?

The answer, apparently, begins with honesty about what you are defending against. The Marmot threat model is not a marketing document. It is an engineering specification. And that distinction, more than any feature comparison, tells you what kind of project this is.