Private communications over public infrastructure

Rev.1

Today I want to write down some thoughts on what it really means to have private communications over public infrastructure, and whether such a thing is even possible at all.

This article was motivated (or should I say triggered?) by several things. Part of it comes from the current state of DMs in Nostr. Part of it comes from the privacy claims different projects make. And part of it comes from recent conversations I have had, also because I care about privacy. Privacy is crucial. We need to fight for it, and if we get it wrong and just assume things are private when they are not, things are going to get very scary.

I want to set the ground first, then look at the privacy model and tradeoffs of the main private-communication approaches built on or around Nostr: NIP-04, NIP-17, Marmot, Nostr Double Ratchet, Concord, Nymchat, NIP-4e, and Cordn.

First things first: private communications and encrypted communications are not the same thing.

Private communications usually depend on encryption to protect message content. But encryption alone is not enough to make a communication system private. You may encrypt what you say, yet still expose who you are talking to, when you are talking, how often you are talking, where you are connecting from, and how large your messages are. A third party can still learn a lot. This is metadata leakage, and in many cases, it is enough to build a revealing picture of relationships and behavior between different parties without reading a single message. Metadata is not "just data." It is actionable intelligence.

In other words: Encryption protects what you say; privacy protects that you said it at all.

That distinction matters a lot in Nostr because Nostr was never designed as a private messaging network. It was designed to be an open network built around relays. Those relays are meant to be queryable, subscribable, "dumb", and easy to use as public dissemination infrastructure. That design is powerful for openness and censorship-resistance, but it is hostile to strong privacy by default.

The next thing I want to clarify is the concept of public infrastructure. From the perspective of this article, it refers to shared, openly accessible systems or mediums, sometimes controlled by a third party, that anyone can use but that lack inherent controls to prevent interception, inspection, or eavesdropping by unauthorized parties. In this context, that includes networks, protocols, and services like relays.

Public infrastructure fights privacy at every layer, which is exactly why the distinction between encryption and privacy matters so much here.

One historic precedent makes this easier to understand. During World War II, encrypted radio traffic itself was not always immediately decryptable, but the metadata around that traffic was already useful. Timing, frequency, origin, volume, and communication patterns helped infer enemy movements, unit locations, and operational behavior. In other words, not being able to read the message did not mean the communication was private. The metadata still spoke loudly, and that lesson maps uncomfortably well to modern digital systems.

"We kill people based on metadata," stated by Michael Hayden, former director of the NSA and CIA, during a 2014 debate at Johns Hopkins University.

"Metadata absolutely tells you everything about somebody’s life. If you have enough metadata, you don’t really need content." Stewart Baker, former NSA General Counsel

That is also why I am skeptical every time I hear privacy claims built on top of public, observable infrastructure. If the substrate is public, queryable, persistently collectable, and operated by third parties, then metadata becomes part of the threat model whether we like it or not.

In Nostr, this problem becomes very concrete.

Even if a DM standard encrypts the content, an observer can still learn a lot. If the observer is a relay operator, it can see when a client connects. It can see the IP unless the user adds another protection layer such as Tor or a VPN. It can see when an event arrives. It can store traffic over time and build heuristics. An external observer with access to the relay stream may also infer a lot, depending on how much metadata the event exposes publicly.

I also think it is useful to distinguish two different kinds of observers throughout this article.

The first is an external observer. This is someone who can collect publicly visible events from relays, subscribe to public streams, and analyze what is exposed in the events themselves. An active observer could also infer the arrival time of an event even if its timestamp is randomized. This observer does not necessarily run the relay.

The second is a relay operator observer. This observer has a much stronger vantage point. They can see connection timing, source IPs unless users hide them, exact arrival timing, authentication attempts, and all the relay-local heuristics that never appear in the event itself.

That distinction matters because some protocols hide more from the external observer than from the relay operator. A scheme can look much better at the public event layer while still leaking a lot to the operator actually serving the traffic.

There is one more thing the relay operator can see that I want to name explicitly, because every protocol in this article is affected by it and we will come back to it. When a client fetches from a relay, it does not just receive events. It also publishes a subscription filter describing what it wants. That filter is metadata too, and it is almost never obfuscated. So even protocols that hide content, and that partially hide the author inside the event, still broadcast their routing interest at subscription time. I will call this filter observability, and it belongs specifically to the relay operator vantage point, since the external observer sees only published events and not your subscriptions.

I also want to push the relay operator model one step further, because it is easy to think of relays as passive storage with a few policies attached. They are not. They are active participants. A relay can delay, drop, or reorder a specific user's events. It can selectively serve stale or incomplete state. It can fingerprint a user through its filters and act on what it learns. It can refuse service entirely. Redundancy across many relays lowers the chance that any single relay harms you, but it does not remove the class of risk, because you still do not control the substrate you depend on. That will matter later when we talk about sovereignty, because the word is doing more work than it should.

There is an attempt to mitigate part of this for external observers with relay auth, aka NIP-42, which allows clients to authenticate to relays. That can help a relay restrict access to sensitive events. But NIP-42 is not a privacy cure. It is a gatekeeping mechanism. In practice, it requires the client to reveal its identity to the relay in order to gain access. And for a relay to know which private events a user is allowed to fetch, those events usually need enough routing information to tie them to the relevant participants. That is useful operationally, but it comes with a clear tradeoff: access control becomes entangled with metadata exposure.

So the question I want to explore in this article is not whether Nostr can carry encrypted messages. It clearly can. The real question is whether it can support private communications over public infrastructure in a strong sense, or whether what we really get are different degrees of content secrecy with different amounts of metadata leakage.

That is the lens I want to use for the rest of this article.

NIP-04

NIP-04 was the first DM standard Nostr had. Today it is deprecated and explicitly marked as not recommended in favor of NIP-17, but it remains the cleanest example of the distinction I am trying to make.

In NIP-04, the message content is encrypted, but the event metadata is highly revealing. The event is authored by the sender’s real pubkey, although anyone could use an ephemeral pubkey. The receiver is identified in a p tag. The timestamp is visible. The event kind is visible. And the ciphertext size is visible as well.

That means the content may be hidden, but the communication pattern is not.

If you are an external observer collecting these events, you can map who is talking to whom and when. If you are a relay operator, you can usually do even better because you also see connection-level information and exact receipt timing. Even if a client tries to blur some timing details, the relay still sees when the event actually arrived.

So what does NIP-04 really give us? It gives us encrypted content, but it leaks social graph information, timing, sender identity, receiver identity, and payload size. That is already enough for strong traffic analysis. You do not need to decrypt anything to extract valuable intelligence from it.

This is not even a controversial interpretation. The specification itself warns that it leaks metadata and says it should not be used for anything that really needs to be kept secret, except perhaps in combination with authenticated relay restrictions from NIP-42.

That said, there is one thing NIP-04 does have going for it. Since sender and receiver are explicit, it works relatively naturally with relay authorization models. A relay can restrict access to the parties involved because the parties are visible in the event. But that convenience is also part of the privacy failure. The same metadata that helps a relay gate access also helps an observer understand the communication graph.

So NIP-04 is simply encrypted communication, but not private communication in any strong sense. It is the perfect example of why those two ideas must not be conflated.

NIP-17

After NIP-04, Nostr moved toward NIP-17, which uses NIP-44 encryption together with gift wraps. This was a real step forward.

The biggest improvement is that NIP-17 does a better job hiding the sender from the public outer event. The gift wrap is authored by an ephemeral key, and the actual message with the real sender is carried inside nested encrypted layers. On top of that, clients are encouraged to randomize timestamps to make simple timing correlation harder.

All of that is meaningful. I do not want to undersell it.

But I also do not want to pretend it solves the problem.

The receiver still needs a way to receive messages. In practice, that means the outer event still carries routing information for the receiver. An active observer can see that gift wraps are being delivered to some receiver-facing key. It can observe timing, volume, relay overlap, and ciphertext size. If the observer is a relay operator, it can also observe connection behavior. An external observer may not get the full picture that NIP-04 leaks publicly, and that is an important improvement, but important metadata is still available.

There is also another tradeoff that matters for the broader story. Gift wraps help obscure purpose because the same mechanism can be used for more than just DMs in Nostr. More specifically, the kind gift wraps use, 1059, is not exclusive to private chats. That is genuinely good for privacy, since not every gift wrap is obviously a chat message. An external observer seeing a kind 1059 event cannot automatically conclude that it is DM traffic. But the same design also creates a broad spam surface. An attacker can cheaply create many gift-wrap-looking events for a target receiver and force the receiver to spend resources figuring out which ones are real, or bury them under a pile of fake gift wraps. This spammy nature is also why some relays do not accept them.

I do not want to focus too much on UX in this article, but this is one of those places where privacy and usability pull in different directions. NIP-17 also gets awkward with relay authentication because the sender uses an ephemeral key, so it does not have a clean way to prove it should be allowed to fetch these events.

So I would describe NIP-17 as a meaningful improvement over NIP-04, especially in sender concealment, deniability, and reduced public visibility. But I still would not call it fully private communication. It is better encrypted communication with a more cautious metadata posture, but not a complete escape from metadata leakage.

Beyond The NIPs Umbrella

The Nostr repository itself mainly gives us NIP-04 and NIP-17, plus the new NIP-4e, which is still a PR. But there are other serious attempts to push the privacy and security model further, and they do not all push in the same direction.

The first two I want to look at, Marmot and Nostr Double Ratchet, bring in much stronger messaging primitives. Marmot brings MLS. Double Ratchet brings the family of ideas popularized by Signal. In both cases, the cryptography becomes substantially more ambitious, giving us things like forward secrecy and post-compromise recovery, which neither NIP-04 nor NIP-17 gives us.

These terms, forward secrecy and post-compromise recovery, basically mean that if a private key is compromised, an attacker should not automatically be able to read historic messages or future messages.

That matters, but it still does not let us skip the transport question. And it is worth saying early that these two are not the whole story. Reading the field as a steady climb, where each new protocol is simply more cryptographic than the last, is tempting but wrong. Later I will look at Nymchat, which takes nearly the opposite route and hardens NIP-17's metadata surface from the client side rather than strengthening the cryptography; Concord, which deliberately gives up some of that cryptographic strength to buy scalable community chat; and Cordn, which questions a premise all of these schemes share, namely that messaging artifacts must be published to public relays at all. The tradeoff space has more than one dimension, and naming that is part of being honest about what each design actually gives you.

Marmot

Marmot combines MLS with Nostr. MLS, short for Message Layer Security, is a serious group messaging protocol designed to provide strong content confidentiality, authentication, forward secrecy, and post-compromise recovery for groups. It also scales much better for larger groups than Double Ratchet. Those are not small properties. They are major upgrades compared with the simpler encrypted-message schemes we find in NIP-04 or NIP-17.

This is something that should be said clearly: MLS gives Marmot genuinely strong secrecy properties at the message layer.

But the problem I am exploring here is not just message secrecy. It is private communications over public infrastructure. That is where the picture becomes more complicated.

Marmot maps MLS artifacts onto Nostr events and uses relays as a dissemination layer. That means things like key packages, welcome flows, group events, and group routing all have to live within a public relay environment. The protocol tries to preserve privacy through encrypted payloads, private MLS group IDs, ephemeral outer pubkeys for group events, and other techniques. Those are meaningful design choices, and they do improve the situation.

But there is an important nuance here. The private MLS group ID and the relay-facing nostr_group_id are not the same thing. In theory that is good because the real internal MLS group identifier stays private. In practice, though, the relay-facing nostr_group_id still behaves like a stable public routing identifier. That means it is observable, it is collectable, and it is spammable in the same way gift wraps are. So even if it is not the real MLS group ID, it still creates a public handle that observers and attackers can use.

This matters even more because Marmot traffic is not especially hard to identify from the outside. If a user publishes key package events on kind 443, or on kind 30443 in the newer transition, that already signals that the user might be using Marmot. And if an observer subscribes to group messages which are kind 445 events, they can infer Marmot group traffic directly. Those event kinds are not generic cover traffic. They are much more revealing than NIP-17 gift wraps, whose kind 1059 can be used for several different purposes in Nostr.

From my perspective, I do not think its current design gets Marmot to strong privacy in the way some descriptions suggest.

The reason is simple. Marmot still operates over public relays. Even if the content is well protected, relays and active collectors can still observe that Marmot is being used. They can see when certain group identifiers become active, when bursts of traffic happen, how much data is flowing, how large the messages are, and which relays appear to be involved. An external observer can infer protocol usage from the specific Marmot kinds used and from the stable routing surface. A relay operator gets all of that plus the usual network-level vantage point, exact arrival times, and IP-level heuristics.

There is another issue: MLS is not just cryptography. It is also coordination. That burden becomes harder in Nostr because relays are a dissemination substrate, not an ordering oracle. Multiple admins can race. Offline members can come back with stale state. Welcome flows and commits need careful discipline to avoid drift.

This is not mainly a privacy problem, but it matters because every time a protocol needs more coordination over weakly ordered public infrastructure, the system inherits more complexity, more observable recovery patterns, and more room for operational fragility. As I already said, I do not want to turn this article into a UX piece. But this is exactly one of those places where the search for stronger privacy and stronger secrecy can make the total system harder to operate.

So my conclusion on Marmot is nuanced.

I think Marmot substantially improves content security and secrecy compared with simpler DM schemes. Thanks to MLS, it brings real forward secrecy and post-compromise recovery, and that is a serious advancement. But I do not think public Nostr relays let Marmot honestly claim strong private communications in the broader sense. Metadata observability and public collection remain very real constraints.

There is an in-progress Marmot v2 draft worth noting because it touches the routing critique directly. v2 formalizes nostr_group_id as admin-gated, rotatable group state, and pins that the value must be cryptographically random and never derived from any member key, which closes one specific cross-group linkage path. But rotation is opt-in rather than scheduled, the rotation commit is published at the old address so the handoff itself is observable and links old to new, and historical traffic stays clustered under the old identifier forever, so v2 softens the stable-routing-ID problem without removing it. The rest of v2, a convergence engine with formal proofs, is correctness and interop work rather than a privacy advance.

Nostr Double Ratchet

Nostr Double Ratchet is the closest thing in this space to bringing a Signal-like messaging primitive into Nostr instead of relying on simpler static encryption flows.

Double Ratchet gives us stronger secrecy properties thanks to forward secrecy and post-compromise recovery. Instead of deriving a static conversation secret and reusing that basic relationship forever, the ratchet evolves keys as messages are exchanged. In practical terms, that means a compromise now should not automatically reveal all past messages, and if the compromise ends, future secrecy can recover after fresh ratchet steps.

That is real progress. Just like with MLS, I think this should be acknowledged clearly rather than buried under transport criticism. If the question is message secrecy, Double Ratchet is much closer to the state of the art than NIP-04, and in an important sense it also improves on the baseline security model around ordinary NIP-17-style direct messaging.

At the same time, Nostr Double Ratchet does not get to cheat physics.

The messages still move through Nostr events and relays. And here the event kinds matter more than they may seem at first glance. In this design, the encrypted outer transport for ordinary ratcheted messages uses kind 1060. That is important because kind 1060 is not generic cover traffic. If an external observer sees repeated kind 1060 events, they can reasonably infer that this specific messaging system is in use, just like in the case of Marmot.

Not every part of the protocol is equally revealing. Invite and AppKeys records use kind 30078, which is a general application-data kind in Nostr and does not by itself prove that Double Ratchet is being used. Encrypted invite responses use kind 1059, which blends into the broader gift wrap universe. Shared-channel bootstrap also leans on kind 4. So there is some reuse of more generic Nostr surfaces. But the core ratcheted message transport still stands out.

That means the outer layer is still informative. An external observer can learn that kind 1060 traffic is happening, see the outer event pubkeys, timestamps, traffic bursts, approximate message sizes, and repeated communication rhythms. Even if they cannot read the content, they can still cluster activity, try to infer which identities or devices are active, and distinguish steady chat traffic from bootstrap traffic such as invites or device-management updates. Those flows also use protocol-specific kinds that do not blend into the general Nostr event stream.

The relay operator learns even more. It sees exact arrival times, subscription behavior, source IPs unless users hide them, and the full local timing picture that never appears in the event itself. At the same time, Double Ratchet does seem to avoid one of the more obvious metadata problems we saw in Marmot: ordinary traffic does not depend on a stable public routing identifier in the event itself.

There is also a tradeoff here around scale. Double Ratchet is naturally attractive for 1:1 communication because it gives strong secrecy with relatively clear security intuition. But it is not the most natural fit for large fanout by itself. The moment it tries to scale those guarantees into more complex group and multidevice environments, the protocol surface and complexity grows quickly. The Nostr Double Ratchet project itself includes multidevice identity mapping, session management, and sender-key-style group messaging, and that is powerful, but it also shows the cost of pushing stronger security models over a public relay substrate. The event kinds used reflect that expansion. Once a system needs separate kinds for encrypted transport, invites, device authorization records, shared-channel bootstrap, and group sender-key flows, an observer gets more protocol fingerprints to work with even if the message bodies remain sealed.

So my take is that Double Ratchet is a major upgrade in secure messaging properties, and it may improve privacy in a limited sense by making traffic less trivially interpretable. If I have to choose a protocol for 1:1 communication over Nostr relays, it would be this one. But it still does not solve the central problem of public infrastructure. The relays still know that communication happened. They still see timing. They still see patterns. And if the infrastructure remains public and observable, those patterns remain part of the attack surface.

Just a side note to finish this. Neither Marmot nor Nostr Double Ratchet play well with relay auth, NIP-42.

Concord

Concord is the protocol behind Vector's Communities, and it is worth looking at because it makes a tradeoff none of the others in this article make, and because it forces us to stop reading the field as a single ladder.

So far the story has looked like a steady climb. NIP-04 to NIP-17 to Marmot to Double Ratchet, each step bringing stronger encryption primitives, with Marmot and Double Ratchet reaching for forward secrecy and post-compromise recovery. It is tempting to read that as one axis, where each new protocol is simply more cryptographic than the last. Concord is the proof that the tradeoff space has more than one dimension.

Before I get into the tradeoffs, one honest caveat about how I am analyzing it. Concord does not have a written specification. The Vector README and the "Understanding Concord" guide are well-written prose, but they describe the product more than they define the protocol. The authoritative behavior lives in the Rust crates, and the team itself says the code is the spec, with golden-vector tests serving as cross-implementation reference points. So everything I say here about Concord is inferred from the code, not read from a document. That matters for an article whose whole argument is that honest, auditable language is part of security. A protocol you can only know by compiling it is harder to hold to its own claims, especially at the metadata layer where informal descriptions tend to be optimistic.

With that said, Concord is built for Discord-style communities: many channels inside a community, roles, admins, bans, the things people actually expect from a group platform. To get there it makes a set of choices that are genuinely well-considered. It uses a shared symmetric channel key per channel and per epoch, so a message is sealed once and every member decrypts the same blob. That is O(1) broadcast, and it is a real property none of the gift-wrap-style schemes have. A room of hundreds of people does not mean hundreds of sealed copies of every message. Authority is handled elegantly too: roles, grants, and bans are real-npub-signed, version-chained records that every member re-derives independently. There is no shared admin key to leak or rotate; authority is a provable place in a signed list, not a secret. And every message carries a real-npub signature inside the encryption, bound to its exact channel and epoch, so forged messages and cross-room splices are detectable even when they come from a key-holding member.

But here is where it matters for this discussion, and I want to be direct. Concord deliberately gives up the two properties Marmot and Double Ratchet worked hardest to provide. It has no forward secrecy and no post-compromise recovery, and that is not an oversight. It is the cost of the random-access epoch model that lets members skip epochs and still catch up. Rekeys use static ECDH between long-term identity keys. The consequence is severe and I want to state it cleanly: if your identity key is ever compromised, an attacker can recover every message you ever had access to, across all of your communities, all channels, all time. There is no cryptographic healing. The only remedy is an admin banning that identity from each community individually.

The shared-key design also widens the blast radius. Because the channel key is symmetric and held by every member, one compromised device exposes the entire channel for that epoch, not just that member's messages. The server root key is broader still. That is the tax on O(1) broadcast: you trade per-member isolation for scale.

And on the question this article keeps coming back to, namely metadata, Concord does not improve on the relay-based schemes. Let me separate the two observers the way I did for the other protocols.

For an external observer just collecting events, Concord is actually one of the most legible designs in this article. Its event kinds, in the 3300 range, are Concord-specific and immediately fingerprintable, and unlike NIP-17's generic kind 1059 they reveal the operation type. An observer can tell message traffic from reactions, edits, rekeys, kicks, and typing indicators. The relay-facing pseudonym, the z tag, lets an outsider group all the traffic for one channel together. Outer events carry real timestamps to the second, not randomized ones, which makes timing correlation easy. So even without running a relay, a collector can confirm Concord is in use, distinguish the operation types, cluster channels, and read traffic rhythms.

The relay operator gets all of that and more. It also sees source IPs, connection timing, exact arrival times, and, returning to the filter observability point from earlier, the subscription filters. That last one bites Concord hardest of all the relay-based protocols, because a client subscribing to a channel has to ask for those specific kinds and that specific channel handle. The subscription itself tells the relay that Concord is in use, which channel the user belongs to, and roughly what operation they are waiting on. That is a lot of structure handed to the relay operator for free.

There is one more nuance worth being candid about. That relay-facing pseudonym rarely rotates. A Public community keeps one stable, trivially-clusterable identifier for its entire lifetime; only bans in a Private community trigger a rotation. So this is not a privacy feature that happens on a schedule. It is a recovery event. But Concord is also a young protocol, and this is exactly the kind of thing that could improve. Scheduled or periodic rotation of that routing pseudonym would meaningfully reduce clusterability, and nothing in the architecture prevents it. The critique here is about the design as it stands today, not a verdict on where it could go.

So where does Concord sit? I would describe it as encrypted communication, not private communication, same as the others, but for a different mix of reasons. It is the design to reach for if the threat model is "no company and no central server reads our community's messages, and we want it to scale," and where long-term identity-key compromise is not the primary concern. It is a poor fit if forward secrecy matters, if metadata matters, or if a compromised member should only expose their own messages. Naming that explicitly is the point. The tradeoff space is not a ladder, and calling Concord more or less private than Marmot without specifying the axis is exactly the kind of imprecision this article is arguing against.

Nymchat

Nymchat, or NYM, takes a route none of the other designs in this article take, and it works on the metadata rather than the cryptography.

Every protocol since NIP-17 has treated the cryptography as the central move. Marmot reaches for MLS, Double Ratchet reaches for Signal-style ratchets, and even Concord, which deliberately trades secrecy away, is still making a cryptographic choice. Nymchat refuses to touch the cryptography at all. Its private messages and group chats are plain NIP-17: a kind 14 rumor sealed in kind 13, gift-wrapped as kind 1059, one wrap per member per group message. The cryptography is the same NIP-17 baseline I already covered, weaknesses included, and Nymchat does not strengthen it. Instead it attacks the metadata surface around it from the client side. Nymchat also runs public geohash and named channels on ephemeral kinds, but those are public chat and outside what this article is asking, so I will leave them aside.

The genuinely interesting contribution is the rotating ephemeral recipient key. In vanilla NIP-17 group sends, Alice publishes N gift wraps addressed to the N members' real pubkeys, all at once. A relay sees N kind 1059 events to N recurring real pubkeys and reads off group membership, size, and existence, durably, on every single message. That is the leak that makes NIP-17 groups so legible. Nymchat breaks it by having each member generate a fresh ephemeral keypair whenever they send, advertise the new pubkey inside the encrypted rumor, and thereafter receive at that one-time key instead of the real one. Every gift wrap now goes to a never-before-seen recipient address.

That genuinely defeats two things: the durable group fingerprint via recurring recipient pubkeys, and the link from recipient addresses back to real identities for active members. This is a real win, and it is exactly the receiver-facing key leak I described in the NIP-17 section.

But Nymchat's own README overstates what it stops, with the line that relays "cannot correlate group membership, timing, or real identities," and I want to be precise about what it does not stop. It does not hide group size at send time: a relay still sees a burst of N gift wraps, even if the recipient addresses are now one-time. It does not hide timing from a live relay, only from an after-the-fact archive reader, because a live operator records actual arrival regardless of the randomized created_at. And it degrades for exactly the members who are least active, since a member who has never sent has no advertised ephemeral key and must be addressed at their real pubkey. The protection assumes an active, sending membership.

Nymchat also randomizes the gift-wrap timestamp by up to two hours using a secure RNG. That is a real but blunt defense: it blurs created_at so an archive observer querying stored events later cannot trivially cluster a group send. The cost is fuzzy real-time ordering, and again it does nothing against a live relay that records true arrival time. It is aimed squarely at the persistent-archive threat model, not the live-relay one.

Nymchat's profile on the axes this article cares about is unusual, and it is the inverse of the Marmot and MLS trade. On content secrecy, forward secrecy, and post-compromise recovery, Nymchat sits at the weak end: NIP-17 baseline, no real FS for groups, optional DM-only per-message FS, and a soft group recovery piggybacked on sending rather than the cryptographic healing MLS provides. On relay-visible fingerprint, though, Nymchat is tied with NIP-17 as the best-behaved relay-based scheme in this article. By refusing to invent new event kinds, its private traffic is generic kind 1059, indistinguishable from any other NIP-17 DM traffic on the relay, which is strictly better than Marmot's 445, Double Ratchet's 1060, or Concord's 3300 range. On filter observability it is also minimal, since subscribing to your own inbox is the same generic NIP-17 filter every DM client uses. And it has no stable routing identifier for private chats at all, because the rotating recipient keys are specifically a move away from one.

There is one uncomfortable thing the article's lens forces me to flag. The default Nymchat deployment routes through Cloudflare Pages Functions operated by 21 Million LLC, acting as a proxy for relays and media, generating link previews, and running its bot. So if a user runs the default client, an operator sits in the traffic path and can observe IPs, timing, and relay selection. The reproducible-build verification and the warrant canary are real and laudable mitigations for trust in that deployment, but they do not remove the vantage point. This is the "runs a service" tradeoff, and it is the same question that will come up again with Cordn later in this article, except here the service is a third-party operator the user does not control. Nymchat's protocol-level metadata discipline only delivers its full story when the user pairs its default ephemeral identity with a relay set of their own choosing rather than the hosted proxy.

So Nymchat sits at a clear and honest point. It is weaker cryptography than Marmot, Double Ratchet, or Cordn, but more metadata-aware than any relay-based scheme here, and it gets there not by inventing new crypto but by refusing to add new observable structure on top of NIP-17. It does not escape the relays, it inherits NIP-17's cryptographic limits, and its default deployment reintroduces a piece of the observer vantage it works so hard to remove at the protocol layer. But as proof that you can meaningfully improve privacy over NIP-17 without touching the cryptography, it is the strongest example in this article.

NIP-4e

NIP-4e is a bit different from the other things I have covered so far, because it is not really trying to be a standalone DM protocol. It is better understood as an auxiliary mechanism that can be used together with schemes such as NIP-04 or NIP-17.

Its core idea is to decouple encryption from identity.

That may sound subtle, but it solves a real problem. Many Nostr patterns assume the identity key is also the key used for encryption, including self-encryption flows used for syncing data across devices. That breaks down in setups where the identity key is intentionally not present on the device, like bunkers, threshold signing systems, secure enclaves, or other more sovereign key-management architectures. NIP-4e tries to fix that by letting a user keep a separate encryption key and distribute that capability securely across devices.

From an architectural point of view, I think that is a good idea.

It improves key hygiene. It makes local encryption workflows more practical. It lets someone keep their identity signing setup more isolated while still doing encryption on-device. And it fits better with a world where people want a stronger separation between identity authority and application-level encryption.

But if we bring it back to the main question of this article, the answer stays modest.

NIP-4e does not suddenly make communications private. If you use NIP-4e together with NIP-04, you still inherit the metadata exposure of NIP-04, even if the keys used are not the real keys. If you use it with NIP-17, you inherit the strengths and weaknesses of NIP-17. What changes is not the public nature of the transport, but the keying model.

In fact, the protocol introduces a privacy cost of its own that is worth naming directly. The device key-sharing and key-package artifacts that NIP-4e relies on publish each of a user's devices as a distinct public record. An observer can count those devices, watch them come and go, and correlate per-device activity, which means building a fingerprint of someone's hardware footprint and routine without ever reading a message. That is device enumeration, and it sits on top of whichever transport model you pair NIP-4e with, so it persists whether you combine NIP-4e with NIP-04 or with NIP-17. It does not make NIP-4e bad. It just means it should be evaluated honestly. NIP-4e is useful infrastructure for decoupled encryption and multi-device sovereignty, and it can support other DM standards. But by itself it is not a privacy breakthrough, and the device graph it exposes is a real cost to weigh.

Cordn

Cordn is the design in this article that questions a premise all the others share, and I think it is the most interesting one to end on.

Every messaging protocol I have covered so far, NIP-04, NIP-17, Marmot, Double Ratchet, Concord, Nymchat, keeps its artifacts on public relays. Those events are collectable and queryable, and all but Nymchat, which deliberately blends into generic gift-wrap traffic, are fingerprintable to a protocol-specific kind. That is the problem I keep returning to, and up to this point every design has accepted it as a fact of life and tried only to encrypt the content inside.

Cordn does not accept it. To be clear about how it uses Nostr, because it would be easy to misread this: Cordn still runs over relays. What changes is what lives on them. Cordn is a coordinator-assisted MLS protocol, and none of its messaging artifacts, whether KeyPackages, Welcomes, group messages, or join requests, ever persist as cordn-specific events on a relay. Instead they live on a coordinator service, and that coordinator is reached through ContextVM, a general-purpose protocol for reaching services through relays without direct public exposure. The only thing the relay actually carries is generic, encrypted, ephemeral ContextVM traffic, which blends with every other ContextVM usage and does not name groups, channels, recipients, or message types. So Cordn does use Nostr relays as its transport, but it stores nothing on them, and nothing a relay collects can be tied back to a cordn conversation later.

That single architectural difference changes the metadata picture in a way none of the others manage. There are no cordn event kinds for an external observer to fingerprint, nothing like Marmot's 443 and 445, Double Ratchet's 1060, or Concord's 3300 range. Group identifiers are coordinator-internal, not public network-wide artifacts, which is a direct fix to the stable routing identifier I criticized in Marmot. And cordn traffic blends into all the other ContextVM usage on the relay instead of standing out as a legible protocol stream.

Now the part I care about most, because it answers the strongest observer this article set up at the start. Remember that the relay operator was defined as the scary vantage point because it sees the protocol-level events and the network layer in the same hands: what you do and where you are, at once. Cordn severs that convergence. The coordinator handles all the protocol-specific activity, group liveness, message volume, timing, join traffic, but it never sees an IP, because clients never connect to it directly. They reach it through relays. The relay, in turn, sees the IP but sees only generic ContextVM traffic, with no group IDs, no cordn kinds, no recipients, no operation types. The party that can interpret the traffic cannot locate you, and the party that can locate you cannot interpret the traffic.

That is a structural answer to the article's own strongest threat model, and no relay-based scheme can offer it by construction. It also collapses the filter observability leak: a cordn client's subscription is a generic ContextVM filter to reach a coordinator, not a request for protocol-specific kinds. The relay learns at most that some IP is talking to some ContextVM service, maybe a coordinator or not, and nothing about groups or channels.

It is worth being precise about the observer set too, because this is where Cordn's improvement is categorical rather than marginal. In the public-relay model the observer set is unbounded, persistent, and self-selecting: anyone who cares to subscribe or collect, today or in a year against a stored archive, is an observer forever. In Cordn it is bounded, finite, and chosen: one coordinator, replaceable, and if self-hosted, literally you. The honest one-liner is that it trades a large set of shallow, permanent observers for a small set of deep, chosen ones.

Now the hard part, because I do not want to oversell it, and there are real costs to weigh.

Cordn is the only protocol in this article that runs a service, and on the surface that looks like centralization. It is, partially. A coordinator can observe that a group is active and learn timing and volume patterns for the traffic it handles. It can delay, drop, or censor delivery, so availability trust remains. But it is worth being clear that this is not a new or unique risk introduced by Cordn's model. Every public relay in every other protocol in this article can do exactly the same: observe, delay, drop, or censor. The difference is only who that party is and how many of them there are. The coordinator never sees plaintext, because MLS protects that, and ordinary message posting can use ephemeral transport keys, so it does not even need to learn stable participant identities for routine traffic.

But here is the inversion I want to be precise about. That centralization can also make the system more private, and the reason is that the coordinator holds delivery, not custody. Everything that matters cryptographically, epoch keys, the ratchets, the member tree, KeyPackage secrets, lives client-side on each member's device. The coordinator is a signaling and delivery service, not a state authority. So if a coordinator is compromised, subpoenaed, loses its database, or turns hostile, what is at risk is the backlog of undelivered ciphertext queued there, the pending Welcomes and join requests not yet consumed, and the activity it can observe during the window it is your active coordinator. What is not at risk is the group itself, its membership, its history on members' devices, or the ability to continue. The group survives the coordinator.

And migration is designed in, not emergent. Per-group cursors exist specifically to preserve ordering across a move, which means a group can jump from one coordinator to another because groups do not care which coordinator they live in. It is fair to call that designed-for. The honest caveats are that concurrent multi-coordinator operation is not yet specified, since the protocol is young and intentionally keeps one active write target per group to preserve MLS ordering, that migration loses any backlog you have not drained first, and that migration is recovery, not prevention of harm done during a specific sensitive window. Marmot also keeps MLS secrets local, so secret-custody locality is shared between them. Cordn's specific edge is the migratable ordered delivery point, not the local custody.

There is one more thing that makes Cordn's privacy story practical rather than theoretical. Recent experiments have shown a coordinator that can run from a browser tab, even from a single HTML file you open locally. That turns the ephemeral-coordinator option from a power-user move requiring Docker and a key into something trivial: save a file, open it, talk, close the tab, and there is no server, no logs, no persistent state anywhere. The win is disposability and zero persistent state, not extra network anonymity, since the coordinator still inherits the machine's IP. But disposability is exactly the property you want for a sensitive one-off conversation, and it is the thing no relay-based scheme can ever offer, because relays persist events by design.

So my take on Cordn is that it is the design in this article that takes the central question, can private communication exist over public infrastructure, most seriously. It does not achieve perfect privacy. The coordinator still observes activity, availability trust is real, and the IP decoupling weakens if client and coordinator share relays or against a global active adversary correlating across both layers. But it is the only design willing to abandon the "everything is a public relay event" purity to actually shrink the public-observability surface, and the only one that lets the user choose who the observer is. Its single architectural move neutralizes several observables at once: the protocol fingerprint, the stable routing identifier, the filter leak, and the convergence of IP and protocol visibility. For a lot of threat models that is a more honest and more useful answer than stronger encryption layered over the same observable transport.

Conclusions

So, is private communication over public infrastructure even possible?

After going through all of these approaches, my answer is still: yes, in some sense, but not really, with one important wrinkle that the last design in this article forced me to take seriously.

Every design that keeps its artifacts on public relays, NIP-04, NIP-17, Marmot, Double Ratchet, Concord, Nymchat, leaks enough metadata that I would not call it private communication in the strong sense. They sit at different points in a tradeoff space, and that space has more dimensions than it first appears: content secrecy, forward secrecy, post-compromise recovery, metadata observability, scalability, coordination cost, and the blast radius of a compromised key. Concord is the clearest proof that you cannot collapse that into a single ladder of "better crypto." It deliberately gives up the forward secrecy and post-compromise recovery that Marmot and Double Ratchet provide, in exchange for scalable communities and keyless verifiable authority. That is a legitimate design point, not a failure, but it would be a failure to market it as simply more private.

To make the tradeoff space legible, here is a compact comparison across the axes that actually vary.

Protocol	Forward secrecy	Post-compromise recovery	Relay-visible fingerprint	Filter leak	Stable routing ID	Group scale
NIP-04	No	No	Protocol-specific (kind 4)	High	Yes (p)	N/A
NIP-17	No	No	Generic (kind 1059)	Medium-high	Yes (receiver)	N/A
Marmot	Yes	Yes	Protocol-specific (443/445)	High	Yes (nostr_group_id)	Good
Double Ratchet	Yes	Yes	Protocol-specific (1060)	High	No	Poor
Concord	No	No	Protocol-specific (3300 range)	High, very legible	Yes (z)	Good (O(1))
Nymchat	Optional (DM only)	Soft (rotation)	Generic (1059, blends with NIP-17)	Low / generic	No (rotating keys)	O(N) (NIP-17)
Cordn	Yes	Yes	Generic (ContextVM)	Low / generic	No (coordinator-internal)	Good

Read the table as a map, not a ranking. No row wins. Each design pays for its strengths somewhere in another column.

A note on the fingerprint column, which is binary rather than a gradient. I have no anonymity-set measurements to justify ranking one design's traffic as "more" identifiable than another's, so the column only records whether the protocol rides on an event kind specific to it, which makes it trivially recognizable, or a kind shared with other traffic. "Generic" means an anonymity set, not invisibility: NIP-17 and Nymchat blend into the gift-wrap population, and Cordn blends into other ContextVM usage, but once a coordinator's pubkey is known a relay can count exactly how much traffic is addressed to it, so Cordn's effective anonymity set is comparable to gift wraps rather than larger. That is why Cordn sits in the same generic bucket as NIP-17 and Nymchat, not above it.

The one design that genuinely strains my pessimism is Cordn, because it is the only one that stops publishing protocol artifacts to public relays. By moving delivery onto a coordinator reached through general-purpose ContextVM transport, it eliminates the protocol-specific fingerprints every other scheme leaks, removes the stable public routing identifiers, collapses the filter leak to generic traffic, and severs the convergence of IP visibility and protocol visibility. And because that coordinator can be self-hosted, even spun up for a single session in a browser tab and discarded, it turns the observer vantage point into something the user can choose instead of something every adversary on the relay gets for free.

Before I land, I want to interrogate one word that this whole ecosystem, including this article's earlier framing, uses too easily: sovereignty.

Two very different things get conflated under it. Exit sovereignty means you can leave any single relay and find another, and that is what Nostr actually delivers. It is real, and it matters. Control sovereignty means you govern the substrate you depend on, and for public relays nobody has that. The operator has it; you do not. Redundancy across relays buys you exit sovereignty, because it dilutes the chance that any one relay's policy harms you. It does not buy control, and it does not eliminate the class of risk. Over the long term, rate limits, kind restrictions, event flushing, wholesale database wipes, and quietly coordinated behavior across relays all still bite. And as I argued earlier, relays are not passive storage with policies. They are active participants that can delay, drop, reorder, selectively serve stale state, fingerprint you through your filters, or refuse service. Selection among uncontrolled infrastructures is not sovereignty over them.

That distinction lets us say something precise about the field. Almost every protocol here earns authority sovereignty, meaning no company or central server dictates membership or roles, because the crypto verifies client-side. Almost none of them earn transport sovereignty, meaning the ability to run the dissemination you actually depend on. You cannot easily run "the public relay layer" on behalf of your partners. But you can run a coordinator, even from a browser tab. Cordn is the only design in this set where both layers can be sovereign. It is worth being clear about scope too: relays being active adversaries threatens availability and metadata, not content secrecy or authority integrity, which client-side verification protects. Naming that keeps the criticism accurate rather than sweeping.

If there is a lesson across all of these, it is this. The protocols most serious about metadata are exactly the ones willing to give something up to escape the observability trap, whether that is the "everything is a public relay event" purity, or even some cryptographic properties. They do it by keeping custody and state client-side so no intermediary can hold the group hostage, and by making the one remaining trust point small, soft, chosen, self-hostable, and migratable. In other words, by converting an unbounded, persistent, self-selecting observer set into a bounded, disposable, user-controlled one.

That is the real answer to whether private communication over public infrastructure is possible, and it is neither the defeatist "not really" nor a triumphalist "this one wins." Pure public relays are mostly not workable in the strong sense, because relays are unbounded, persistent, active observers you do not control. The designs that escape do so by relocating the observer into something you can run, replace, or discard. If we want to be honest, we cannot collapse all of that into the word private and move on.

I intentionally kept this piece focused on privacy rather than UX, even though the two constantly touch each other. But it is hard to read through these protocols without noticing that better secrecy and a better privacy posture often come with costs in complexity, spam resistance, coordination, recoverability, or general usability.

Encrypted is not the same as private. Public infrastructure is not a neutral carrier. And if we want private communications on top of public systems, we have to be far more demanding about metadata, far more honest about tradeoffs, and far more precise in the claims we make.