NIP-17: Private Direct Messages
NIP-04 encrypted the text; NIP-17 tries to hide the conversation
NIP-17 exists because NIP-04 was not enough. The older direct-message standard encrypted the message body but left sender, recipient, timing and kind visible to relays. For a public relay network, that is a serious metadata leak.
The modern approach uses layers. The actual chat message is an unsigned rumor, usually kind 14. That rumor is encrypted into a kind 13 seal using NIP-44. The seal is then encrypted again into a kind 1059 gift wrap using NIP-59 and a fresh random wrapper key. Each receiver gets a separate gift wrap, and the sender gets a copy for recovery.
The point is not perfect secrecy. The point is to make public relay storage less revealing. A relay sees a gift-wrapped event addressed to a recipient. It cannot learn the real sender, the real message kind, the real timestamp or the conversation group from public data alone.
Rooms, DM relays and message rumors
NIP-17 defines rooms by the sender pubkey and p tags. A one-to-one chat is the common case, but small rooms with more than two peers exist. If the participant set changes, the standard treats it as a new room with clean history. A subject tag can name or rename the conversation.
Publishing depends on kind 10050, the user's preferred DM relay list. The sender looks up the recipient's DM relay list and publishes the gift-wrapped events only there. If no list exists, the official text treats the recipient as not ready to receive this private-message scheme.
The rumor definitions give the readable inner shape. Kind 14 is a chat message with plaintext content after unwrapping. Kind 15 is an encrypted file message with file metadata, hash fields, thumbnail hints and decryption material. Kind 7 reactions can also travel inside encrypted chats by convention.
The DM replacement became a three-NIP stack
NIP-17 arrived in April 2024 through Vitor Pamplona's sealed, gift-wrapped private messaging work, originally discussed around old NIP-24 and PR #686. The encrypted chat master thread #717 is a useful map of the split: NIP-44 for encryption, NIP-59 for gift wrap and NIP-17 for the messaging protocol that uses both.
The file has kept moving because private messaging is never only cryptography. In 2025, Vitor removed marker requirements and added q tags, Water added kind 15 encrypted file messages, and alltheseas clarified publishing instructions. In 2026, hodlbod added deletion behavior and fiatjaf clarified spam and relay-auth guidance.
That history matters for people. NIP-17 is current, but still draft. It is the active path away from NIP-04, not a claim that private messaging on Nostr has no open design pressure.
Private chat is now a relay, signer and spam problem
OpenSats describes NIP-17 as the current standard for private DMs and names Damus, Amethyst, Primal, 0xChat and Coracle among clients implementing it. 0xChat's Dart library lists NIP-17, NIP-44 and NIP-59 support. Rust Nostr documents sender and receiver flows for NIP-17. The implementation footprint is real.
The hard part is not only wrapping and unwrapping. Clients need to discover kind 10050 relay lists, publish copies to each receiver and the sender, verify the seal pubkey matches the rumor pubkey, group messages by room membership, support deletion and editing expectations and explain why a user may not receive messages if their DM relays are missing.
Relays have a harder spam problem than with public posts. The outer wrappers use random keys, so normal pubkey reputation is weaker. The official text points to NIP-59 spam protection and NIP-42 authenticated access for serving kind 1059 only to p-tagged users. Private messaging therefore depends on relay behavior as much as client cryptography.
Better metadata privacy does not make group chat easy
The official limitation is clear: every receiver needs a separate encrypted event. For a one-to-one chat that is fine. For larger group chats it becomes heavy, and the NIP itself says rooms with more than ten participants need a more suitable messaging scheme.
The second risk is false privacy copy. NIP-17 hides much more than NIP-04, but relays still see that a recipient is receiving gift wraps, clients can leak metadata through poor timestamps or relay choices, and spam defenses can weaken privacy if implemented clumsily. A good client explains the improvement without overselling it.
Read NIP-17 in the wild
NIP-17 is the modern private direct-message shape. It uses the gift-wrap and encryption stack instead of repeating the old NIP-04 model, which means the interesting work is metadata reduction, wrapping, delivery and recoverability.
The standard does not make private messaging effortless. You still need to explain relay choice, recipient keys, message recovery and what remains visible. Privacy improves only when the interface tells the truth about the envelope around the message.
What changes when you actually use it
For you, NIP-17: Private Direct Messages 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-44, NIP-59, NIP-42, NIP-21 as the surrounding map before trusting the room label.
What changes for builders and operators
For builders, NIP-17: Private Direct Messages 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 Chat Rooms, Encrypting, Publishing, Relays, Delete, edit and disappearing messages, Benefits & Limitations, Spam, Message Rumor Definitions. Inspect kind 14, kind 15, kind 7, kind 13, kind 1059, kind 10050, kind 5, draft because these are the pieces most likely to surface as product behavior. Read it beside NIP-44, NIP-59, NIP-42, NIP-21 before treating it as isolated.
NIP-17: Private Direct Messages needs honest audience language. Public, private, group, encrypted, temporary and moderated are different promises.
Where it breaks
The failure mode in NIP-17: Private Direct Messages 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-17: Private Direct Messages 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-17: Private Direct Messages is using one room word for several protocols. Chat, public chat, private DM, group, forum thread, comment and encrypted envelope are different. Read NIP-44, NIP-59, NIP-42, NIP-21 and keep the interface honest about which promise is actually present.
Language that keeps the feature honest
Good product copy for NIP-17: Private Direct Messages 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-17: Private Direct Messages 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-17: Private Direct Messages 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-44, NIP-59, NIP-42, NIP-21 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: Encrypted Chat Master Thread #717, NIP-44 Versioned Encryption, NIP-59 Gift Wrap, OpenSats topic: Private DMs. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-17 source is the anchor for exact wording, and NIP-17 commit history shows how that wording moved over time. The strongest secondary clues here are Encrypted Chat Master Thread #717, 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-17: Private Direct Messages: first the human promise, then kind 14, kind 15, kind 7, kind 13, kind 1059, kind 10050, then the implementation record, then the real-world failure case. That order keeps NIP-17 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 14,kind 15,kind 7,kind 13,kind 1059in the official file and check where the UI exposes the same concept. - Read NIP-44, NIP-59, NIP-42, NIP-21 as context before treating NIP-17 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-17: Private Direct Messages in that order: Official NIP-17 source for the current wording; NIP-17 commit history for the change record; Encrypted Chat Master Thread #717, 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.
