NIP-18: Reposts
A social network needs sharing without pretending every share is a reply
NIP-18 is the Nostr standard behind the thing users recognize as a repost, boost or share. It sounds like a feed feature, but the protocol problem is deeper. If one person wants to point followers at another person's event, clients need a way to preserve attribution, relay hints and thread structure without inventing a different local format in every app.
The first form is simple: a kind 6 event says that a kind 1 text note is worth reading. The repost includes an e tag for the original event ID, a relay hint so the note can be fetched and usually a p tag for the original author. The content can contain the JSON of the reposted note, although NIP-70 protected events keep that content empty.
The second form is quieter but just as important. Quote posts and mentions use q tags so the quoted event is not pulled into a reply thread. That distinction saves product surfaces from becoming messy: a quote is a public reference, not a child reply. It can be counted, fetched and displayed without changing the conversation tree.
Kind 6, kind 16 and the q-tag boundary
Kind 6 is intentionally narrow. It is reserved for reposting kind 1 text notes. That means a client can treat kind 6 as a familiar feed boost and know the repost target is a note-shaped object.
Kind 16 is the generic repost for everything else. If a user reposts an article, a file, a community post, a badge, a listing or another non-note object, kind 16 gives the action a standard envelope. The NIP asks generic reposts to include a k tag with the target event kind. When the target is addressable, an a tag carries the event coordinate. If that coordinate is missing, the content contains the full JSON of the specific event version being reposted.
The q tag is the quote layer. Mentions of NIP-21 entities such as nevent, note or naddr become q tags. That gives clients a cheap way to fetch and count quotes while keeping reply queries clean.
A standard removed, restored and then stretched by real clients
The file history tells a more human story than a repost spec normally would. Fiatjaf added NIP-18 at the start of 2023 through PR #140, then removed it two weeks later with the blunt commit message that it was not really a standard. Issue #173 captured the discomfort around that removal, especially because Damus and Snort were already shaping repost behavior in practice.
Arthur Franca brought NIP-18 back in March 2023, first restoring the event copy and then allowing optional commentary. Fiatjaf then narrowed the wording again so the standard returned to its original intent. In June 2023, kind 16 generic reposts arrived, making reposts work beyond text notes.
The later history is mostly about edge cases that real products expose. William Casarin moved quote reposts toward q tags in 2024. Jon Staab and others clarified address quotes, NIP-21 references and generic reposts. In late 2025, Vitor Pamplona normalized q tags with NIP-22, while Cody Tseng improved reposts of replaceable events. That trail shows why reposts are not a small UX flourish. They sit exactly where social product behavior meets event identity.
The feature looks simple; the fetch path is not
A clean repost implementation has to do more than draw a boost icon. It needs to keep the original author visible, use relay hints well, avoid turning quote posts into replies, count quotes separately from comments and decide what to do when the reposted event is missing on the user's current relays.
Nostr.co.uk lists broad client support for NIP-18 across familiar apps such as Damus, Primal, Amethyst, Snort, Coracle, nostrudel and Iris. Nostrbook lists kind 16 as Generic Repost. The Elixir nostr_lib documentation still exposes a repost parser for kind 6, while warning around older interpretation. These implementation traces are useful because they show both adoption and drift.
The sharp edge is addressability. Reposting a current profile-like object, a long-form article or another addressable event is not the same as reposting a single immutable note. The a tag points at the object coordinate, while copied JSON points at one version. Product designers have to decide whether the repost means 'this object' or 'this exact historical version.'
Reposts can blur context faster than they spread it
The main risk is context loss. A repost can travel farther than the original conversation, and a client that hides author, relay or quote context can make borrowed content look detached from its source. NIP-18 gives machines the structure; the interface still has to preserve credit and caution.
Another risk is thread pollution. If clients mistake quote references for replies, conversations become unreadable. If clients ignore generic repost tags, non-note content becomes second-class even when the user clearly intended to share it. Repost support is therefore part social UX, part relay fetch logic and part standards hygiene.
Read NIP-18 in the wild
NIP-18 gives reposts a portable form. Reposting looks simple in a feed, but it has two jobs: carry another event into your audience and preserve enough reference to prove what you are amplifying.
The product risk is quote confusion. A repost is not authorship, endorsement is not always agreement, and a deleted or missing original changes what the repost means. Clients need to show the original source clearly.
What changes when you actually use it
For you, NIP-18: Reposts is felt when an app either behaves predictably or suddenly loses context. The visible symptom may be a missing reply, a broken link, a strange reaction count, an empty result or a relay error that looks like the whole network failed. The official terms kind 6, kind 1, kind 16, draft, content, e are where that visible behavior begins, so the source is not background material; it is the place where the product promise gets its limits.
What changes for builders and operators
For builders, NIP-18: Reposts is compatibility discipline. Implement kind 6, kind 1, kind 16, draft, content, e against more than one relay and more than one library, then test malformed, missing and duplicated data. Core standards fail most painfully when the happy path looks fine and the second client exposes the shortcut.
What the official file makes concrete
The official file is organized around Quote Reposts, Generic Reposts. Inspect kind 6, kind 1, kind 16, draft, content, e, id, p because these are the pieces most likely to surface as product behavior. Read it beside NIP-70, NIP-21 before treating it as isolated.
NIP-18: Reposts is a shared contract between independent software. The smallest field can become user-visible when two clients disagree about it.
Where it breaks
The failure mode in NIP-18: Reposts is often indirect. Nobody complains about kind 6, kind 1, kind 16, draft, content, e; they complain that the feed is wrong, the reply vanished or the relay behaved strangely. Use the official file to diagnose the hidden cause instead of patching only the visual symptom.
Where this appears outside the markdown
In the ecosystem, NIP-18: Reposts is not something most people choose directly. It is the invisible grammar behind clients, relays, crawlers, search tools and archives. When a product team treats kind 6, kind 1, kind 16, draft, content, e as implementation detail only, the mistake eventually reaches the surface as missing history, bad threading or state that cannot be reconstructed after a client switch.
The nearby-standard trap
The nearby-standard trap in NIP-18: Reposts is assuming the base layer solves the higher-level feature. This NIP may define the common grammar, but publishing, wallets, moderation, media or groups still need their own constraints. Read NIP-70, NIP-21 to see where the base contract ends and the product-specific promise begins.
Language that keeps the feature honest
Good product copy for NIP-18: Reposts does not say "the protocol handles it" and move on. It explains the visible consequence: what was sent, what was accepted, what was rejected, what is still loading and what another relay or client may show differently.
What this page does not promise
NIP-18: Reposts does not promise a finished social product. It gives software a shared grammar. Feed design, moderation, ranking, notifications, storage duration and recovery remain separate product decisions. That distinction matters because a client can be technically compatible and still give you a weak experience if it hides relay errors, drops context or treats optional fields as if every app understood them.
Read it as a field test
Start NIP-18: Reposts with the visible product symptom, then trace it back to kind 6, kind 1, kind 16, draft, content, e. That order keeps the article grounded: you see why the field exists, which relay or client behavior depends on it, and where adjacent standards change the story. A core NIP is strong only when it explains both the normal path and the awkward edge case.
Where the standard earns trust
The source links give you places to test the interpretation in public: PR #140: NIP-18, Issue #173: NIP-18 improvement debate, Issue #1101: NIP-10 / NIP-18 conflict, Issue #2121: replaceable reposts. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-18 source is the anchor for exact wording, and NIP-18 commit history shows how that wording moved over time. The strongest secondary clues here are PR #140: NIP-18, Issue #173: NIP-18 improvement debate, Issue #1101: NIP-10 / NIP-18 conflict. 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-18: Reposts: first the human promise, then kind 6, kind 1, kind 16, draft, content, e, then the implementation record, then the real-world failure case. That order keeps NIP-18 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can two independent clients read the same
kind 6,kind 1,kind 16,draftwithout a hidden compatibility rule? - Does the UI explain relay rejection, missing context or state replacement without blaming the whole network?
- Which adjacent standard, especially NIP-70, NIP-21, changes the behavior once the base event leaves the happy path?
What to verify before you rely on it
- Find
kind 6,kind 1,kind 16,draft,contentin the official file and check where the UI exposes the same concept. - Read NIP-70, NIP-21 as context before treating NIP-18 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-18: Reposts in that order: Official NIP-18 source for the current wording; NIP-18 commit history for the change record; PR #140: NIP-18, Issue #173: NIP-18 improvement debate, Issue #1101: NIP-10 / NIP-18 conflict 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.
