NIP-04: Encrypted Direct Message
The first DM path Nostr outgrew
NIP-04 matters because it was Nostr's early answer to a basic social-product question: how do two users send each other encrypted direct messages? It defines kind 4 events with encrypted content and a recipient p tag. For early clients, that was enough to make private messaging possible.
It is also a standard that aged in public. The current official file is final but unrecommended, and the README says it is deprecated in favor of NIP-17. That combination is important. Final does not mean recommended forever. It means the old behavior is defined clearly enough that legacy messages can still be interpreted.
A good NIP-04 page therefore has two jobs. It has to explain what old clients were doing, and it has to warn people away from treating that old path as modern privacy.
Kind 4, encrypted content and visible metadata
A NIP-04 event uses kind 4. The content field is a base64 AES-256-CBC ciphertext, followed by a base64 initialization vector as a query-style iv parameter. The shared secret comes from combining the recipient's public key with the sender's private key through ECDH; the Nostr version uses the X coordinate of the shared point rather than the default hashed secret used by some secp256k1 APIs.
The recipient is not hidden. The event includes a p tag identifying the receiver so relays can forward it naturally. The event author is also visible through the signed NIP-01 wrapper. That means the message body may be encrypted while the social metadata remains exposed.
The official file now says this plainly. The security warning says the standard does not approach state-of-the-art encrypted peer communication and leaks metadata. The client warning also matters: clients must not process public-key or note references inside the encrypted content as if it were a public text note, because adding tags can leak the mentioned users.
The warnings arrived before the replacement became normal
The visible NIP-04 history starts with the 2022 migration of the early NIPs. It was finalized in late 2022, but by March 2023 the file already gained an explicit security warning. Bartholomew Joyce added a metadata leak warning, and fiatjaf added broader caution around the standard.
The replacement story becomes visible in later commits. Paul Miller's NIP-44 encryption standard landed in the NIPs history in December 2023. Vitor Pamplona's NIP-17 sealed gift-wrapped private messaging work landed in April 2024. By the current README, NIP-04 is deprecated in favor of NIP-17.
That sequence is useful for people. NIP-04 was not foolish for its time; it was an early minimal encrypted-DM path. The ecosystem then learned that encrypted content is not enough when sender, recipient, timing and relay behavior remain legible.
Still useful for migration, not a modern privacy promise
NIP-04 still appears in libraries and older clients because legacy data exists. Implementations such as nostr-tools historically exposed NIP-04 helpers, and many clients built DM features around kind 4 before NIP-17 became the preferred path. Removing all NIP-04 understanding would strand old conversations.
New product work needs to read NIP-04 mainly as compatibility and migration context. Modern Nostr private messaging is better understood through NIP-17, which uses NIP-44 encryption and NIP-59 gift wrapping to reduce visible metadata. That does not magically solve every privacy problem, but it directly addresses the biggest NIP-04 weakness.
The product rule is simple: support legacy messages if necessary, label the privacy level honestly, and avoid designing new sensitive workflows around kind 4.
Encrypted text is not private communication by itself
NIP-04 is the cleanest cautionary tale in the early NIP set. A message can be encrypted and still leak the relationship graph. A relay can see kind 4 events, author keys, recipient tags and timing. A client can accidentally leak mentions by processing encrypted content like public notes. A user can read 'encrypted' and assume far more protection than the standard provides.
That does not make NIP-04 useless. It makes it historical infrastructure. The fair reading is to preserve it for compatibility, explain it clearly and route new work toward NIP-17/NIP-44/NIP-59.
Read NIP-04 in the wild
NIP-04 is the old encrypted direct-message pattern. It made private-ish messaging possible early in Nostr, but its limits are now part of the lesson: old encryption, visible metadata and a mental model that can make a public relay network feel more private than it really is.
Read it as migration material. If you are handling old DMs, you need compatibility. If you are building new private messaging, compare it with NIP-17, NIP-44 and NIP-59 so you do not freeze a legacy privacy model into a modern product.
What changes when you actually use it
For you, NIP-04: Encrypted Direct Message is felt inside the room: who can read, who can reply, what remains visible and what the interface makes private by implication. Messaging standards are risky because familiar chat design can smuggle in promises the protocol never made. Read NIP-17 as the surrounding map before trusting the room label.
What changes for builders and operators
For builders, NIP-04: Encrypted Direct Message is expectation control. Test the same conversation across relays, devices and clients. Make audience, persistence, encryption and moderation visible. A chat-shaped interface can feel private even when the event is public, and that mismatch is a product bug.
What the official file makes concrete
The official file is organized around Security Warning, Client Implementation Warning. Inspect kind 4, unrecommended, relay, content, "content": "<encrypted_text>?iv=<initialization_vector>", tags, ["p", "<pubkey, as a hex string>"], ["e", "<event_id>"] because these are the pieces most likely to surface as product behavior. Read it beside NIP-17 before treating it as isolated.
NIP-04: Encrypted Direct Message needs honest audience language. Public, private, group, encrypted, temporary and moderated are different promises.
Where it breaks
The failure mode in NIP-04: Encrypted Direct Message is false intimacy. The room feels like a messenger, but storage, audience, reply context or metadata tell a more public story. This is where copywriting, UI labels and protocol behavior need to match exactly.
Where this appears outside the markdown
In the ecosystem, NIP-04: Encrypted Direct Message touches the most emotionally familiar interface: a conversation. That makes it easy for products to borrow the comfort of chat, groups or DMs while the actual protocol object has different privacy and delivery properties. The page has to slow that moment down before the interface creates a false expectation.
The nearby-standard trap
The nearby-standard trap in NIP-04: Encrypted Direct Message is using one room word for several protocols. Chat, public chat, private DM, group, forum thread, comment and encrypted envelope are different. Read NIP-17 and keep the interface honest about which promise is actually present.
Language that keeps the feature honest
Good product copy for NIP-04: Encrypted Direct Message names the room. It says public, encrypted, relay-scoped, group-controlled, archived, temporary or moderation-aware when those things are true. It avoids borrowing private-message comfort for data that travels more openly.
What this page does not promise
NIP-04: Encrypted Direct Message does not turn every conversation into a private room. A chat-like screen can hide public relays, visible metadata, partial delivery, missing devices or moderation rules that only live on one server. The safe reading is concrete: who can read, where does the event live, what does encryption cover, and what happens when one client leaves?
Read it as a field test
Start NIP-04: Encrypted Direct Message with the audience. A message-like interface earns trust only when public, private, encrypted, group-scoped and relay-scoped behavior are not blurred. Read NIP-17 before drawing product conclusions, because most messaging mistakes come from using the wrong room model for the event in front of you.
Where the standard earns trust
The source links give you places to test the interpretation in public: NIP-17 Private Direct Messages, NIP-44 Versioned Encryption, NIP-59 Gift Wrap, Nostr Compass NIP-04 overview. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-04 source is the anchor for exact wording, and NIP-04 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-17 Private Direct Messages, NIP-44 Versioned Encryption, NIP-59 Gift Wrap. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-04: Encrypted Direct Message: first the human promise, then kind 4, unrecommended, relay, content, "content": "<encrypted_text>?iv=<initialization_vector>", tags, then the implementation record, then the real-world failure case. That order keeps NIP-04 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who can read the event, and does the screen say that before you type?
- What metadata remains visible even when content is encrypted or wrapped?
- Can another client recover the thread, room or message history without pretending delivery is guaranteed?
What to verify before you rely on it
- Find
kind 4,unrecommended,relay,content,"content": "<encrypted_text>?iv=<initialization_vector>"in the official file and check where the UI exposes the same concept. - Read NIP-17 as context before treating NIP-04 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-04: Encrypted Direct Message in that order: Official NIP-04 source for the current wording; NIP-04 commit history for the change record; NIP-17 Private Direct Messages, NIP-44 Versioned Encryption, NIP-59 Gift Wrap for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
