Chapter 23 - Media
23
Nostr Implementation Possibility - Hex № 23

Long-form Content

Articles and blog posts as editable Markdown events. Write once, revise forever, keep one stable address.

1 Overview

A kind-1 note is short and frozen. An article is long and lives on. This NIP defines kind 30023 for long-form text content, generally called an article or a blog post.

Kind 30023 is an addressable event as defined in NIP-01. The relay keeps only the latest event for each pubkey + kind + d-tag-value triple. So the author can edit an article. Readers always fetch the newest version at the same address.

The content is Markdown. Metadata such as the title, a cover image, and a summary travel in tags. A stable NIP-19 naddr code links to the article from anywhere.

This NIP is optional. "Social" clients that deal primarily with kind-1 notes are not expected to implement it.

Warning!

Kind 30024 is deprecated. It carried long-form drafts: the same format as kind 30023, self-encrypted with NIP-04. Do not use it for new drafts. Use NIP-37 draft events instead.

Tech Note

The source spec describes the deprecated kind 30024 only as "self-encrypted nip04, same format as kind 30023". It never specifies the encryption procedure in detail. Treat old 30024 events as best-effort legacy data. Also, the spec's own example event carries a published_at of 1296962229 (year 2011), earlier than its created_at and earlier than Nostr itself. It is placeholder data, not a rule.

2 Format

The content of a kind-30023 event is a string of text in Markdown syntax. The goal is maximum compatibility and readability across clients and devices. A client that creates long-form notes must follow two hard rules:

  • MUST NOT hard line-break paragraphs of text. Do not insert arbitrary line breaks, for example at 80-column boundaries.
  • MUST NOT support adding HTML to the Markdown.
Wire format - kind 30023 article
{
  "kind": 30023,
  "created_at": <unix ts of the LAST update, seconds>,
  "content": <article body, Markdown, no HTML, no hard line breaks>,
  "tags": [
    ["d", <stable article identifier>],
    ["title", <article title>],          // optional
    ["image", <cover image URL>],         // optional
    ["summary", <article summary>],       // optional
    ["published_at", <unix ts, string>],  // optional
    ["t", <topic hashtag>], ...            // optional
  ],
  "pubkey": <author>, "id": <...>, "sig": <...>
}

3 Metadata Tags

Use the created_at field for the date of the last update. Use t tags for "tags" or "hashtags": topics for which the article is relevant. Other metadata fields can be added as tags when necessary. This NIP standardizes four of them. All four remain strictly optional.

Metadata reference
Tag / fieldValuePurpose
dstring identifierThe stable address of the article. Required for editability. See §4.
titlestringThe article title.
imageURLAn image to show along with the title.
summarystringThe article summary.
published_atstringified unix secondsThe timestamp of the first time the article was published.
tstringA topic hashtag. Repeat the tag for each topic.
created_atunix seconds (event field)The date of the last update.
Hint!

Editing moves created_at forward with each revision. Keep published_at fixed at the first release. Show published_at as the byline date and created_at as "last updated".

4 Editability

Articles are meant to be editable. Each article must include a d tag with an identifier for the article. To publish a new version, sign a new kind-30023 event with the same d value. The relay replaces the old version.

Clients should take care to publish and read these events only from relays that implement addressable replacement. If a relay does not implement it, clients should also take care to hide old versions of the same article that they may receive.

Author Relay Reader EVENT 30023, d:"my-post", v1 EVENT 30023, d:"my-post", v2 relay keeps only v2 REQ {"kinds":[30023], ...} EVENT v2 (latest only)
Fig. 23-1 — Edit cycle. A new event with the same d value replaces the old article. Readers get only the latest version.

5 Linking and References

Link to an article with the NIP-19 naddr code along with the a tag. The a tag form is defined in NIP-01: ["a", "30023:<pubkey>:<d value>", <relay URL, optional>].

References to other Nostr notes, articles, or profiles must follow NIP-27. Write them inside the content as NIP-21 nostr:... links. Optionally add matching e or a tags for these references, as the example in §7 shows.

kind 30023 published article kind 30024 draft - DEPRECATED naddr + a tag stable address NIP-37 drafts preferred linked by replaced by
Fig. 23-2 — Kinds and addresses. Kind 30023 is the article. The naddr code addresses it. Kind 30024 drafts give way to NIP-37.

6 Replies and Comments

Replies to a kind-30023 article MUST use NIP-22 kind 1111 comments. Do not reply with kind-1 notes. The comment carries the article's address, so it survives edits of the article.

7 Worked Example

The event below is the spec's example article, published and then confirmed by the relay. The content holds NIP-27 nostr: references. The e and a tags mirror those references.

Session transcript - wss://relay.example.com
-- author publishes the article --
→ ["EVENT", {
    "kind": 30023,
    "created_at": 1675642635,
    "content": "Lorem [ipsum][nostr:nevent1qqst8cujky046negxgwwm5ynqwn53t8aqjr6afd8g5…]
      dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt
      ut labore et dolore magna aliqua. […] Read more at nostr:naddr1qqzkjurnw4ksz…",
    "tags": [
      ["d", "lorem-ipsum"],
      ["title", "Lorem Ipsum"],
      ["published_at", "1296962229"],
      ["t", "placeholder"],
      ["e", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87",
            "wss://relay.example.com"],
      ["a", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum",
            "wss://relay.nostr.org"]
    ],
    "pubkey": "…", "id": "…", "sig": "…"
  }]
← ["OK", "…", true, ""]

-- a reader fetches the article by address --
→ ["REQ", "art", {"kinds":[30023], "authors":["…"], "#d":["lorem-ipsum"]}]
← ["EVENT", "art", { "kind":30023, "tags":[["d","lorem-ipsum"], …], … }]
← ["EOSE", "art"]

8 Version History

NIP-23 changed its addressing scheme several times in its first weeks. Then it settled. Notable changes, newest first:

  • 20262026-05Deprecated kind 30024 drafts in favor of NIP-37.
  • 20252025-03Replies to articles must use NIP-22 kind 1111 comments.
  • 20242024Renamed "parameterized replaceable event" to "addressable event"; removed a stale NIP-12 mention.
  • 20232023-07Added the formatting rules: no hard line breaks, no HTML in Markdown (William Casarin).
  • 20232023-05Suggested kind 30024 for encrypted drafts (Alejandro Gomez).
  • 20232023-03Switched references in content to NIP-27 nostr: links.
  • 20232023-02Early churn: nref became nitem, then naddr; the i tag became a; the YAML frontmatter and the NIP-01 bridge event were dropped.
  • Origin2023-02-03fiatjaf published "NIP-23: long-form content."

Original Proposal - Credits

Authorfiatjaf
First commit2023-02-03 — “NIP-23: long-form content.”
Statusdraft - optional — social clients may skip it
Source23.md on GitHub - full change history

9 See Also

  • NIP-01 — addressable events, the d tag, and the a tag that this NIP builds on.
  • NIP-22 — kind 1111 comments, the mandatory reply format for articles.
  • NIP-19 — the naddr bech32 code that links to an article.
  • NIP-21 — the nostr: URI scheme used inside the Markdown.
  • NIP-27 — how to write references to notes and profiles in content.
  • NIP-37 — draft events, the replacement for deprecated kind 30024.