NIP-84: Highlights
A highlight is not just a quote pasted into a feed
You often want to save one sentence from an essay, article, podcast transcript, code page or Nostr note. Before NIP-84, clients could fake that by publishing a normal note, but the result lost the useful structure: where the passage came from, who wrote it, whether the URL was cleaned, and what surrounding context needs to travel with it.
NIP-84 gives highlights their own event kind, 9802. The selected text lives in content. Source references use a or e tags for Nostr-native material and r tags for web URLs. Attribution can include multiple p tags, with roles such as author or editor.
That changes the product surface. A reading app can build a personal commonplace book. A social client can show quote highlights without turning them into duplicate notes. A search tool can index what people found valuable, not just what people published first.
Kind 9802 plus source, attribution and context tags
The event is small but intentionally rich. The content field is the highlighted passage, and it may be empty for non-text media. Source tags point to the original object. A URL needs to be cleaned of trackers where possible. A context tag can carry the surrounding paragraph when the selected line would otherwise lose meaning.
The April 2025 quoted-highlights change added the comment tag. That lets a user add their own remark while still preserving the highlighted passage as the quoted object. Mentions inside that comment must be marked as mentions, and the original source URL must be marked as source.
The subtlety is important. The highlight, its source and the user's comment are different things. NIP-84 keeps them separate enough that clients can render them honestly.
The standard was simplified before it became useful
Pablo Fernandez introduced NIP-84 through the Highlights PR in November 2023. The early file had more range machinery, but fiatjaf removed that complexity days later with the plain explanation that it could be added later if real need appeared. That decision made the NIP easier to ship.
William Casarin added quoted highlights in April 2025, and fiatjaf later connected HTML link rel=me discovery to attribution. The history shows the NIP moving from a basic annotation format toward a bridge between reading tools, web pages and Nostr-native content.
The useful reading is practical: NIP-84 is not a generic bookmark. It is a signed record of what someone selected and why that selection points back to a source.
A good client treats the source as first-class
A highlight client must not only show the selected text. It needs to show the source, the author if known, the user's comment if present, and enough context to prevent misleading quotation. For web sources, URL cleanup and stable canonical URLs matter because highlights are only useful when they can be found later.
Clients that support quote highlights needs to avoid double-posting a kind 1 note and a highlight that say the same thing. NIP-84 exists partly to stop that clutter.
Indexers can also use this event as a weak signal of value: not the number of likes on a post, but the passages people bothered to save.
A highlight can become a bad quote if context is missing
Highlights are powerful because they extract. They are risky for the same reason. A line can be clipped from its argument, stripped of authorship or attached to the wrong URL. Clients need to reward context, source display and attribution rather than only the punchiest sentence.
Copyright and fair-use boundaries also matter. NIP-84 defines an event shape, not permission to mirror large copyrighted works.
Read NIP-84 in the wild
NIP-84 turns highlights into portable reading signals. A passage from an article, book or web page can become a signed object with context.
Highlights can mislead when they travel without source, author, surrounding text or timestamp. Serious reading tools need citations and recovery paths, not only pretty quote cards.
What changes when you actually use it
For you, NIP-84: Highlights 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 9802, kind 1, draft, kind:9802, .content, a decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-84: Highlights 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, References, Attribution, Context, Quote Highlights. Inspect kind 9802, kind 1, draft, kind:9802, .content, a, e, p because these are the pieces most likely to surface as product behavior. Read it beside NIP-94 before treating it as isolated.
NIP-84: Highlights 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-84: Highlights 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-84: Highlights 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-84: Highlights 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-94 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-84: Highlights 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-84: Highlights 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-84: Highlights 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 9802, kind 1, draft, kind:9802, .content, a. 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: Highlights PR #501, Quoted highlights PR #1438, nips.nostr.com NIP-84. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-84 source is the anchor for exact wording, and NIP-84 commit history shows how that wording moved over time. The strongest secondary clues here are Highlights PR #501, Quoted highlights PR #1438, nips.nostr.com NIP-84. 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-84: Highlights: first the human promise, then kind 9802, kind 1, draft, kind:9802, .content, a, then the implementation record, then the real-world failure case. That order keeps NIP-84 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 9802,kind 1,draft,kind:9802to render the work without private context?
What to verify before you rely on it
- Find
kind 9802,kind 1,draft,kind:9802,.contentin the official file and check where the UI exposes the same concept. - Read NIP-94 as context before treating NIP-84 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-84: Highlights in that order: Official NIP-84 source for the current wording; NIP-84 commit history for the change record; Highlights PR #501, Quoted highlights PR #1438, nips.nostr.com NIP-84 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.
