NIP-23: Long-form Content
Nostr needed articles, not only notes
NIP-23 is the standard that lets Nostr carry essays, blog posts, newsletters and other long-form text without pretending everything is a short note. Kind 1 is excellent for timelines. It is a poor home for a maintained article with a title, image, summary, publication time and future edits.
The NIP defines kind 30023 as an addressable event for long-form content. Addressable means the object is not only an immutable event ID. It has a coordinate built from kind, author and d tag, so a newer version can replace an older one while the article keeps a stable identity.
That distinction is why NIP-23 matters for an all-encompassing Nostr wiki or media archive. A protocol article, a creator essay, a project announcement or a publication page can live as a Nostr object, be linked by naddr, mirrored on the web and commented on without becoming a fragile screenshot of a timeline post.
Markdown, metadata and editable identity
The content field contains Markdown. The NIP is strict about compatibility: long-form clients do not hard-break paragraphs at arbitrary 80-column widths and do not add HTML inside Markdown. That protects people across clients and devices. A long article has to render predictably even when it moves between apps.
The metadata lives in tags. title names the article. image points at a cover image. summary gives the excerpt. published_at records the first publication time. Topic tags use t. The created_at field represents the latest update.
The d tag is the stable identifier for editability. Clients read and publish from relays that understand addressable events, hide old versions when necessary and link articles through NIP-19 naddr. References inside the article use NIP-27 text references and NIP-21 nostr: links. Replies and comments use NIP-22 kind 1111.
Long-form became the first serious publishing object
Fiatjaf added NIP-23 in February 2023. The same early work touched NIP-19 because addressable long-form content needed shareable references. A few days later the text moved away from YAML frontmatter, fixed title/content wording and followed the naming path from nref to nitem to naddr.
In March 2023, NIP-23 references were adapted to use NIP-27. Alejandro Gomez added kind 30024 draft guidance in May 2023. William Casarin added formatting guidance in July 2023 to protect cross-client readability. In 2024, the naming shifted to addressable events. In 2025, Vitor Pamplona connected long-form replies to NIP-22 comments.
The 2026 Drafts change is also important: kind 30024 is deprecated for long-form drafts, and NIP-37 draft wraps become the preferred path. That is the kind of living standard change you need to see. NIP-23 is not only 'articles on Nostr'; it is an evolving publishing contract.
NIP-23 is where Nostr becomes a publishing substrate
Real NIP-23 usage appeared quickly. A 2023 Stacker News post describes trying long-form publishing through Habla and Blogstack. The nostrability interoperability tracker lists long-form article support and labels across Habla, Highlighter, Primal, Snort, Damus, Coracle, Ditto, gossip and other clients or relays. Drupal even has a Nostr long-form content module for publishing kind 30023 and older 30024 events from a CMS context.
Nostrbook's kind 30023 page explains the implementation duties clearly: render Markdown, support updates with the same d identifier, show the latest version, parse metadata and handle naddr references. That is a much more complex job than showing a short note in a feed.
The product boundary is also explicit in the NIP: social clients focused on kind 1 notes are not expected to implement long-form publishing. A good NIP-23 you is closer to a magazine, blog or knowledge-base renderer than a timeline card.
Publishing needs stronger guarantees than a timeline
The first risk is version confusion. If clients show multiple old versions or disagree about the latest event for a coordinate, an article can appear inconsistent across the network. Addressability solves the identity problem, but clients and relays still have to apply replacement rules cleanly.
The second risk is rendering drift. Markdown is not one thing in practice. If clients allow HTML, hard-break paragraphs differently or mishandle Nostr references, a carefully written article becomes uneven across apps. NIP-23's formatting constraints are not pedantry; they protect people.
The third risk is source durability. Long-form articles often depend on images, file hosts and relay availability. A serious publisher has to think about media storage, relay strategy, backups, signatures and web mirrors. NIP-23 gives the article shape; it does not guarantee the whole publishing stack.
Read NIP-23 in the wild
NIP-23 is the long-form article standard. It gives writing a title, summary, image, publication time, tags and addressability so an essay can move between clients instead of being trapped in one editor's database.
That matters for creators because an article is not just a longer note. It is a published object with metadata, revisions, citations and archive expectations. A serious client treats the article as a piece of work, not a stretched timeline post.
What changes when you actually use it
For you, NIP-23: Long-form Content 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 30023, kind 30024, kind 1, kind 1111, draft, kind:30023 decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-23: Long-form Content 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 Format, Metadata, Editability, Linking, References, Example Event, Replies & Comments. Inspect kind 30023, kind 30024, kind 1, kind 1111, draft, kind:30023, kind:30024, kind:1 because these are the pieces most likely to surface as product behavior. Read it beside NIP-37, NIP-19, NIP-27, NIP-21, NIP-22 before treating it as isolated.
NIP-23: Long-form Content 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-23: Long-form Content 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-23: Long-form Content 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-23: Long-form Content 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-37, NIP-19, NIP-27, NIP-21, NIP-22 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-23: Long-form Content 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-23: Long-form Content 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-23: Long-form Content 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 30023, kind 30024, kind 1, kind 1111, draft, kind:30023. 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: nips.nostr.com NIP-23 mirror, Nostrbook kind 30023, nostrability long-form tracker, Drupal NIP-23 module. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-23 source is the anchor for exact wording, and NIP-23 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-23 mirror, Nostrbook kind 30023, nostrability long-form tracker. 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-23: Long-form Content: first the human promise, then kind 30023, kind 30024, kind 1, kind 1111, draft, kind:30023, then the implementation record, then the real-world failure case. That order keeps NIP-23 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 30023,kind 30024,kind 1,kind 1111to render the work without private context?
What to verify before you rely on it
- Find
kind 30023,kind 30024,kind 1,kind 1111,draftin the official file and check where the UI exposes the same concept. - Read NIP-37, NIP-19, NIP-27, NIP-21, NIP-22 as context before treating NIP-23 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-23: Long-form Content in that order: Official NIP-23 source for the current wording; NIP-23 commit history for the change record; nips.nostr.com NIP-23 mirror, Nostrbook kind 30023, nostrability long-form tracker 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.
