Note

A Gift Wrap Hides the Sender, Not the Envelope: What NIP-17 Private Messages Still Leak

NIP-17 gift wraps hide the sender, the real timestamp and the message type, but the outer envelope still names the recipient, and the keys have no forward secrecy.

2026-11-11 · nostr, nip-17, nip-59, nip-44, nip-04, nip-42, private-messages, metadata, threat-model, civil-liberties

Listen · 10 min · AI voice

Dark CryptoDecentral hex mesh — a single sealed bronze hexagonal envelope travels between teal cells; its contents are hidden, but a thin teal thread still runs from it to one destination cell; no text.

People who have been targeted for their communications usually say the same thing: the messages were rarely the problem. The problem was the graph — who talked to whom, how often, and when. A reporter's source, an organiser's contact list, a lawyer's client: the content can stay sealed and the pattern still gives people away.

Nostr has had two answers to private messages. Kind 4 from NIP-04 encrypted the words and published the graph. NIP-17, built on NIP-59 "gift wraps" and NIP-44 encryption, hides much more. It is a real improvement, and it is worth knowing exactly where it stops.

Thesis, stated once: NIP-17 hides the sender, the real timestamp and the message type from the public, but the outer envelope still names the recipient, still travels over a network connection, and still sits on relays that you have to trust to gate it. And the keys underneath have no forward secrecy. Encrypted is not the same as unobservable.

What kind 4 got wrong

NIP-04 is now marked unrecommended and "deprecated in favor of NIP-17". Its own security warning says it "leaks metadata in the events" and "must not be used for anything you really need to keep secret."

The leak is structural. A kind 4 event is an ordinary signed Nostr event. Its pubkey is the sender. A p tag names the receiver. created_at is the real send time. Optional e tags thread replies together. Only content is encrypted (AES-256-CBC with a shared secret from the two keys). So anyone who can read the relay can draw the full conversation graph, timestamped, without decrypting a single byte.

The three layers of NIP-17

NIP-17 wraps each message in three layers, and each layer has one job.

Rumor. The actual message is a kind 14 chat event (or kind 15 for a file) containing the sender's pubkey, the recipients as p tags, the real created_at, and the plain text. It is not signed. NIP-59 says why: a leaked rumor "cannot be verified", which gives "a measure of deniability".
Seal (kind 13). The rumor is NIP-44 encrypted to the recipient and placed in a seal signed by the sender's real key. Tags "MUST always be empty", so the seal says who signed it but not who it's for or what it says.
Gift wrap (kind 1059). The seal is encrypted again and placed in an event signed by a random, one-time key generated fresh for every message. This outer layer carries a single p tag: the recipient.

Clients SHOULD randomise created_at on both the seal and the wrap "up to two days in the past", so the timestamp on a relay doesn't line up with when you actually hit send. The sender also wraps a copy to their own key so their other devices can read the conversation.

One rule every client has to follow: "Clients MUST verify if pubkey of the kind:13 is the same pubkey as that of the unsignedMessageRumor". Otherwise anyone can impersonate anyone by editing the unsigned rumor.

What the public loses, per the NIP's own list: "Participant identities, each message's real date and time, event kinds, and other event tags." There is no public group identifier to count messages against.

What the envelope still says

The recipient is in plain sight. The p tag is the routing label, and it has to be readable so relays can deliver the wrap. Anyone the relay serves that event to learns "this pubkey received a private message." Over time that becomes "this pubkey receives a lot of private messages, at roughly these times."

Hiding the recipient depends on the relay, and the spec only says SHOULD. NIP-17 says relays "SHOULD protect message metadata by only serving kind:1059 events to users p-tagged on the event (enforced using NIP-42 AUTH)." NIP-59 repeats the advice. That is a policy a relay can choose, not a property of the protocol. A relay that serves wraps to anyone exposes every recipient label it stores. A relay that lists NIP-42 in its information document isn't promising to gate reads with it, either.

Your inbox address is public on purpose. Kind 10050 lists the relays where you want to receive DMs, and senders "MUST only publish" to those. So anyone can see where your mail arrives. The NIP tells clients to keep the list small (one to three relays), which helps delivery but also gives an observer fewer places to watch.

The relay can see who's connecting. NIP-59's spam section points out that wraps are signed by throwaway keys, so relays can't rate-limit by reputation. The recommended mitigation is that a relay may require NIP-42 AUTH before accepting wraps, and that clients "support authenticating to such relays using the user's real identity." The NIP notes that AUTH isn't recorded in the event, so this "does not fully undermine" deniability. Read the other way, though: a relay that requires sender AUTH can see which authenticated connection uploaded which wrap, addressed to which recipient. That pairing is visible to the operator, even if the public never sees it.

Size and network leaks remain. NIP-44's padding is "related to powers-of-two, with min padded msg size of 32 bytes", which blurs message length without hiding it. Its limitations list also says it plainly: "IP address leak: user IP may be seen by relays and all intermediaries between user and relay." Nostr's encryption does nothing at the network layer.

What the keys can't do

NIP-44, the encryption under both inner layers, lists its own shortcomings without spin:

"No forward secrecy: when a key is compromised, it is possible to decrypt all previous conversations"
"No post-compromise security: … decrypt all future conversations"
"No post-quantum security"

Gift wraps on kind 1059 are designed to be stored so offline recipients can catch up. NIP-17 lists "Fully Recoverable" as a feature: any client with your private key can rebuild the whole history. Seen from the other side, a leaked nsec opens every stored wrap addressed to you.

NIP-17's "optional forward secrecy" means disappearing messages. Those rely on an expiration tag or on not wrapping a copy to yourself, which is a request to relays, not cryptographic erasure. (The deletion note covers why a request isn't erasure.) NIP-59 also defines an ephemeral wrap, kind 21059, which relays "MUST NOT store". It's useful for live sessions, but you still depend on the relay to honour it.

The deniability is partial too. The rumor is unsigned, but the seal carries the sender's real signature, and NIP-59 calls the result "a measure of deniability", not deniability.

And the scheme has a size limit. Every recipient gets a separate wrap, so the NIP says groups "with more than 10 participants should find a more suitable messaging scheme."

A sober checklist

Treat the recipient label as public unless you've confirmed your inbox relays only serve wraps to the p-tagged key after AUTH. Test it yourself rather than trusting a feature list.
Choose your kind 10050 relays the way you'd choose a mail host. They see your incoming volume and timing.
Assume a leaked nsec opens your stored history. How you handle keys (signers, separate keys for different roles) does more here than any client setting. See the nsec note.
Use a client that checks seal pubkey against rumor pubkey. It's a MUST, and skipping it allows impersonation.
Hide your IP separately if your threat model needs it. Tor or a trusted network path is a separate layer; NIP-17 doesn't provide it.
Use the right tool for high risk. NIP-44's own advice: "users should chat in specialized E2EE messaging software and limit use of nostr to exchanging contacts." See the private messaging guide.

For most everyday private chat between Nostr users, NIP-17 is a sound design that hides far more than the old scheme. For someone whose contact graph is the thing an adversary wants, whether a journalist, an organiser or someone living under surveillance, the envelope still matters, and the spec is honest that it does.

What this is not

This isn't a ranking or endorsement of any Nostr client, relay or messenger. It doesn't claim any named relay gates or fails to gate kind 1059 reads, so check for yourself. It isn't security advice for a specific situation; if your safety depends on it, talk to someone who can assess your actual threat model. It doesn't argue against NIP-17, which fixes real problems in kind 4. It isn't a claim that the NIP-44 cryptography is broken; the limits listed above come from the spec itself. And it has nothing to do with tokens, prices, custody or trading. Quotes are from the NIPs repository's master branch as of 11 November 2026; NIP-17 is marked draft, so re-read it before you build on it.

The one-line takeaway: a gift wrap hides who sent it and when, but the envelope still shows where it's going. Choose your relays and protect your keys with that in mind.