NIP-59: Gift Wrap
Private messages needed better metadata separation
NIP-44 encrypts payloads. NIP-59 asks what to do around that payload so the public event leaks less. The answer is a layered construction: rumor, seal and gift wrap.
A rumor is the inner event without a signature. A seal signs and encrypts that rumor to the receiver. A gift wrap then encrypts the seal again and publishes it from a random one-time key, with enough tags for routing. The result is not perfect anonymity, but it separates content, author identity and routing metadata better than a simple encrypted direct message.
NIP-59 explicitly does not define a messaging protocol. NIP-17 private direct messages use it as the private-message construction.
Rumors, seals, persistent gift wraps and ephemeral gift wraps
A rumor is a normal Nostr event with the signature removed. If leaked, it cannot be verified as a signed event. A seal is kind 13, signed by the real author and encrypted to the receiver, but with empty tags so the recipient is not visible on the seal.
A gift wrap is kind 1059. It wraps the seal, is signed by a random one-time-use key and can include routing tags such as the recipient p tag. Kind 21059 is the ephemeral version for real-time cases where relays must not store it.
The NIP also covers timestamp and metadata protection guidance, plus deletion requests for gift wraps. It relies on NIP-44 for encryption.
Gift Wrap kept tightening as private messaging matured
Jonathan Staab introduced NIP-59 Gift Wrap in August 2023. In January 2024, he removed the public p tag from the seal and clarified that NIP-59 does not define a messaging protocol by itself.
In 2025, the NIP gained stronger timestamp and metadata-protection guidance, plus Gift Wrap deletion requests. In May 2026, ContextVM added ephemeral gift wrap kind 21059. A June 2026 change briefly removed id requirements from rumors and then reverted that, showing that even inner-layer details are actively considered.
The history tracks a serious privacy conversation: what can be hidden, what still leaks, and where the message protocol needs to live.
Gift Wrap matters most through NIP-17 private DMs
NIP-59 is easiest to understand through NIP-17. A private direct message becomes a rumor, then a seal, then a gift wrap routed to the recipient. Libraries such as rust-nostr and clients implementing modern private messages need these layers to interoperate.
A client implementing NIP-59 must be strict about empty seal tags, one-time gift-wrap keys, timestamp randomization guidance, NIP-44 validation and message deletion semantics. It needs to also avoid telling users that metadata disappears. The recipient tag on the outer gift wrap is still routing metadata.
The standard also mentions AUTH as part of the answer to spam in NIP-17 and NIP-59 contexts. Private messaging needs delivery, but private inboxes also need abuse controls.
Gift wrapping is privacy improvement, not invisibility
NIP-59 hides more than older encrypted messages, but relays can still see timing, outer kind, recipient routing tags and network behavior. Users must not be sold perfect secrecy.
There is also implementation risk. If a client reuses one-time keys, exposes seal tags, signs rumors or mishandles deletion requests, the layered design loses much of its value.
Read NIP-59 in the wild
NIP-59 gift wrap reduces what the outside of a private message reveals. It is part of the modern messaging stack because encrypting only content still leaves metadata trails.
Wrapping adds complexity. Delivery, timestamps, relay choice, recipient recovery and failure states all need careful UI. Privacy fails when the envelope looks simpler than it is.
What changes when you actually use it
For you, NIP-59: Gift Wrap is felt when identity stops being a username and becomes authority. A client, signer, name, proof or auth event may look like account plumbing, but it decides who can publish, approve, connect, recover or be recognized. Read NIP-44, NIP-13, NIP-17, NIP-42, NIP-09 beside it so you can tell the difference between a convenient identity surface and the key material that actually controls the account.
What changes for builders and operators
For builders, NIP-59: Gift Wrap means making authority visible before action. A signer prompt, name proof, delegation, encrypted key, external identity or HTTP auth event needs plain language around scope, expiry, destination and recovery. If a person has to guess what they are authorizing, the protocol has already lost the trust battle.
What the official file makes concrete
The official file is organized around Overview, Protocol Description, 1. The Rumor Event Kind, 2. The Seal Event Kind, 3. Gift Wrap Event Kind, 4. Ephemeral Gift Wrap Event Kind, Encrypting Payloads, Spam Protection. Inspect kind 13, kind 1059, kind 21059, kind 1, relay, gift wrap, content, kind:13 because these are the pieces most likely to surface as product behavior. Read it beside NIP-44, NIP-13, NIP-17, NIP-42, NIP-09, NIP-62 before treating it as isolated.
NIP-59: Gift Wrap is an authority path, not decoration. A name, key, signer, delegation or auth event decides who can act as you.
Where it breaks
The failure mode in NIP-59: Gift Wrap is authority drift. A name resolves to an old key, a signer approves too broadly, an auth event gets replayed, a delegation lasts too long or a private key backup gives false comfort. The product has to keep control boundaries visible after onboarding, not only during setup.
Where this appears outside the markdown
In the ecosystem, NIP-59: Gift Wrap usually appears at the doorway: account setup, profile recognition, signer approval, cross-platform proof, remote signing, HTTP auth or recovery. That doorway needs unusually clear language because identity mistakes are sticky. Once a key, signer or proof is trusted in the wrong place, every later feature inherits the confusion.
The nearby-standard trap
The nearby-standard trap in NIP-59: Gift Wrap is confusing recognition with control. A name, signer, URI, encrypted key, delegation or auth signature may all sit near identity, but they answer different questions. Read NIP-44, NIP-13, NIP-17, NIP-42, NIP-09 and ask one thing each time: who can act, who can verify, and what can be revoked?
Language that keeps the feature honest
Good product copy for NIP-59: Gift Wrap names the authority. It says whether you are sharing a public key, approving a signature, trusting a domain, exporting an encrypted secret, delegating power or authenticating to a service. Small labels matter because identity mistakes do not feel small after they happen.
What this page does not promise
NIP-59: Gift Wrap does not make identity effortless or risk-free. It can help keys, names, signers, delegation or authentication become portable, but it cannot decide who you trust, how you back up secrets or whether a domain, app or signer deserves authority. Read NIP-44, NIP-13, NIP-17, NIP-42, NIP-09 as a control map before handing any interface the power to sign, verify or speak for you.
Read it as a field test
Start NIP-59: Gift Wrap with the moment of authority: signing, naming, delegation, authentication, encryption or recovery. Then ask which key or service can act. The source terms kind 13, kind 1059, kind 21059, kind 1, relay, gift wrap are useful because they turn vague identity language into concrete control points. Without that, a friendly login screen can hide the most important security decision.
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, PR #2245, rust-nostr. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-59 source is the anchor for exact wording, and NIP-59 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-17 Private Direct Messages, NIP-44 Versioned Encryption, PR #2245. 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-59: Gift Wrap: first the human promise, then kind 13, kind 1059, kind 21059, kind 1, relay, gift wrap, then the implementation record, then the real-world failure case. That order keeps NIP-59 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who gains authority when this NIP is used: your key, a signer, a domain, a delegated key, a wallet or a web service?
- Can you revoke, rotate, back up or inspect that authority before something goes wrong?
- Does the interface separate public recognition from private signing power in language you can act on?
What to verify before you rely on it
- Find
kind 13,kind 1059,kind 21059,kind 1,relayin the official file and check where the UI exposes the same concept. - Read NIP-44, NIP-13, NIP-17, NIP-42, NIP-09 as context before treating NIP-59 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-59: Gift Wrap in that order: Official NIP-59 source for the current wording; NIP-59 commit history for the change record; NIP-17 Private Direct Messages, NIP-44 Versioned Encryption, PR #2245 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.
