NIP-37: Draft Wraps
Publishing needs a backstage
Nostr is good at public signed events. Drafts are different. A draft is unfinished, private and often unsigned as final content. Writers, podcasters, developers and client users need somewhere to keep work-in-progress without turning it into a public event too early.
NIP-37 gives that backstage a standard shape. A client wraps an unsigned draft event, JSON-stringifies it, encrypts it with NIP-44 to the user's own public key and publishes the encrypted wrapper as kind 31234. The draft can be recovered by the same user later, even from another client that understands the format.
That matters for long-form posts, calendar items, media metadata, marketplace listings and any other event that may need editing before publication. Nostr does not become a serious authoring environment if drafts live only in one browser tab.
Draft wraps, checkpoints and private storage relays
A draft wrap uses kind 31234. Its d tag identifies the draft, and its k tag names the kind of the draft event inside the encrypted content. An expiration tag is recommended so draft storage does not become accidental permanent junk.
A blank content field signals deletion. That detail is easy to miss but important for product behavior: deleting a draft is not the same as publishing a public deletion request for a final event. It is a private-state cleanup signal.
NIP-37 also defines kind 1234 checkpoints for draft revision history, and kind 10013 for private content relay preferences. The private relay list is itself encrypted and needs to be published to the author's NIP-65 write relays. The source recommends that private storage relays use NIP-42 authentication and only allow downloads of events signed by the authenticated user.
From older draft patterns to encrypted draft wraps
The NIP-37 history is tangled because earlier draft work moved between related files. Vitor Pamplona's 2024 commits moved draft material out of NIP-35 and added private outbox relay ideas. In 2025, NIP-37 saw improvements to draft events. In 2026, Pablo Fernandez's Drafts PR shaped the current wrapper language.
The relationship with NIP-23 is important. NIP-23 notes that the old kind 30024 long-form draft approach is deprecated and that NIP-37 is the preferred route for long-form drafts. That makes NIP-37 more than a niche storage trick; it is the current path for draft authoring across event kinds.
The history also shows why this standard is sensitive. Drafts sound simple until you ask where private work is stored, who can fetch it, how revisions work, how deletion works and how a second client finds the right relays.
A draft system is a privacy system with a delete button
The implementation surface is small but unforgiving. A client has to wrap the unsigned event correctly, encrypt the JSON with NIP-44, include the draft kind in k, choose relay storage, recover the draft on another device and handle blank-content deletion.
Checkpoints are useful when a client wants revision history, but they also increase the privacy burden. A product needs to explain whether old draft versions remain recoverable, how long they are kept and which relays hold them.
The private relay list is the operational part. If a client publishes draft wraps to ordinary public relays with no authentication, privacy depends too much on encryption alone. NIP-42 authenticated private storage relays make the design more coherent, but also require better relay UX.
Encrypted drafts still create metadata and storage risk
NIP-37 protects draft content with encryption, but it does not make the existence of drafts disappear. Relays can still see wrapper events, timestamps, authors and storage patterns. A private authoring product needs to be honest about that metadata.
The second risk is recovery confusion. If a user changes clients and the new client does not know the private storage relays, drafts can look lost. NIP-37 only works well when clients make relay choice, expiration and deletion visible enough for normal people to trust.
Read NIP-37 in the wild
NIP-37 is about drafts, which are more sensitive than they sound. A draft can contain unfinished thoughts, private links, legal risk, names you remove later or work that was never meant to be public.
A portable draft is useful only when storage, encryption and deletion are plain. If a client saves drafts to relays without explaining the privacy model, the feature has betrayed the writer before publication even begins.
What changes when you actually use it
For you, NIP-37: Draft Events is felt when a post becomes a durable object: article, file, image, video, audio, bookmark, wiki entry or source reference. The question is whether the work still makes sense after one app, host or relay disappears. The concrete pieces kind 1234, kind 31234, draft, .content, expiration, kind:1234 decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-37: Draft Events is context preservation. Store enough title, tag, author, hash, URL, media, preview and reference material that another interface can rebuild the object. If your feature depends on a private database to make sense, the NIP is not doing the portability work yet.
What the official file makes concrete
The official file is organized around Checkpoints, Relay List for Private Content. Inspect kind 1234, kind 31234, draft, .content, expiration, kind:1234, kind:31234, relay because these are the pieces most likely to surface as product behavior. Read it beside NIP-40, NIP-42, NIP-65 before treating it as isolated.
NIP-37: Draft Events protects context. Titles, media, hashes, source links, timestamps and references decide whether work survives beyond one app.
Where it breaks
The failure mode in NIP-37: Draft Events is link rot with a nice interface. Media disappears, metadata lies, source URLs change, hashes are missing or an article loses its addressable identity. The page needs to make durability part of the feature, not an afterthought.
Where this appears outside the markdown
In the ecosystem, NIP-37: Draft Events is part of the creator and archive layer. It decides whether writing, media, files, bookmarks, wiki material or source references remain understandable after the first app disappears. That is why media standards need to talk about storage, provenance and recovery, not only presentation.
The nearby-standard trap
The nearby-standard trap in NIP-37: Draft Events is flattening every creative object into a note with a link. Articles, videos, files, torrents, highlights, images, wiki entries and bookmarks carry different metadata and storage pressure. Read NIP-40, NIP-42, NIP-65 so the product does not throw away the part that made the object portable.
Language that keeps the feature honest
Good product copy for NIP-37: Draft Events names the object and the storage. It says article, file, image, video, bookmark, wiki page, torrent, highlight or podcast episode, then tells you where the signed metadata ends and where external hosting begins.
What this page does not promise
NIP-37: Draft Events does not guarantee that published work survives forever. It can carry richer metadata, hashes, references or addressability, but files still need hosts, relays still need retention, and clients still need to render the object faithfully. Treat the NIP as the signed map of the work, then check where the actual bytes, previews and source links live.
Read it as a field test
Start NIP-37: Draft Events with the object you want to keep: article, file, media, bookmark, repository, torrent, wiki entry or podcast episode. Then trace which parts are signed, which parts are hosted, and which parts another client can reconstruct from kind 1234, kind 31234, draft, .content, expiration, kind:1234. That is the difference between portable publishing and a pretty link preview.
Where the standard earns trust
The source links give you places to test the interpretation in public: NIP-23 Long-form Content, NIP-44 Versioned Encryption, NIP-40 Expiration Timestamp, NIP-42 Relay Authentication. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-37 source is the anchor for exact wording, and NIP-37 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-23 Long-form Content, NIP-44 Versioned Encryption, NIP-40 Expiration Timestamp. 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-37: Draft Events: first the human promise, then kind 1234, kind 31234, draft, .content, expiration, kind:1234, then the implementation record, then the real-world failure case. That order keeps NIP-37 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Where do the signed metadata and the actual media or file bytes part ways?
- Can the object still be identified by hash, address, title, author and source if the first URL breaks?
- Does a second client know enough from
kind 1234,kind 31234,draft,.contentto render the work without private context?
What to verify before you rely on it
- Find
kind 1234,kind 31234,draft,.content,expirationin the official file and check where the UI exposes the same concept. - Read NIP-40, NIP-42, NIP-65 as context before treating NIP-37 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-37: Draft Events in that order: Official NIP-37 source for the current wording; NIP-37 commit history for the change record; NIP-23 Long-form Content, NIP-44 Versioned Encryption, NIP-40 Expiration Timestamp 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.
