NIP-25: Reactions
Lightweight feedback needed a signed event of its own
NIP-25 is the standard behind the small social signals that make a feed feel alive: likes, dislikes, emoji responses and custom emoji reactions. In Nostr, a reaction is not a database row hidden inside one platform. It is a signed event that can be fetched, counted, filtered and displayed by many clients.
The simple case is kind 7. A reaction points at another Nostr event and puts the reaction value in content. A plus sign or empty content means a like or upvote. A minus sign means a dislike or downvote. An emoji or NIP-30 shortcode is a more expressive reaction and no longer gets mapped to like or dislike.
The result is small but powerful. Reactions become portable social proof. A client can show who liked an article, who downvoted a post, what emoji appeared under a file or how a community responded to a live event. The feature is trivial for a user and surprisingly subtle for interoperability.
Reaction value, target tags and external content
A native reaction needs an e tag pointing at the event being reacted to. The tag includes a relay hint and can include the target pubkey. A p tag points at the author of the target event. If the target is addressable, an a tag carries the coordinate. A k tag can include the target kind number.
The tag order guidance matters because older and newer clients may include extra tags. If a client includes multiple e or p tags, the target event and target pubkey appear last. More recent edits also discourage reaction events from carrying a huge pile of unrelated tags.
NIP-25 now handles external content with kind 17. A website reaction uses NIP-73-style k and i tags, while a podcast reaction can include show and episode identifiers. Custom emoji reactions connect to NIP-30 through an emoji tag and a :shortcode: content value.
Reactions grew from plus and minus into a broader response layer
William Casarin added NIP-25 in July 2022 and quickly clarified dislikes, explicit plus likes and reactions to any note. Later fixes improved examples and grammar. In 2023, Yasuhiro Matsumoto connected reactions to NIP-30 custom emoji, and Ben Carman clarified empty-string reactions as likes.
The 2024 and 2025 history shows the standard widening. Vitor Pamplona added a tags for addressable targets. Don added website reactions. Hodlbod removed the old recommendation to map emoji reactions into like/dislike buckets and added stronger relay/pubkey hints. Oscar Merry added external content reactions in PR #2020.
That movement matters because Nostr is not only a microblogging feed anymore. Users react to articles, files, podcasts, websites, community objects and addressable events. NIP-25 had to grow from 'like a post' into a portable response format.
Reaction counts are easy until identity, addressability and spam enter
NIP-25 appears in many libraries because reactions are part of almost every social client. Net::Nostr documents a NIP-25 reaction module with plus, minus and emoji behavior. Nostrbook's kind 7 page explains reaction storage and tag-filter discovery. 0xChat's Dart library lists NIP-25 support. Rust Nostr lists NIP-25 as implemented.
A client has to do several things well: validate the target event, fetch missing targets from relay hints, avoid counting the same user's repeated reaction blindly, render custom emoji only when the emoji tag is present and make addressable-event reactions point to the object users actually see.
Reactions also touch moderation. A public downvote can be a useful signal or a harassment vector. A custom emoji can be playful or abusive. A relay can store reaction events, but clients decide which reactions become visible product feedback, which become counters and which are hidden by filters or community policy.
A reaction is social metadata, not truth
The first risk is treating counters as objective quality. Reactions are signed events, but they are still gameable, relay-dependent and context-sensitive. A count can differ across relays. A user can react multiple times. A client can choose which reaction to show.
The second risk is notification noise. NIP-25 gives reactions enough structure to notify authors, but not every emoji or external-content reaction deserves the same interruption. Good clients separate signal from spam without hiding the portable event underneath.
Read NIP-25 in the wild
NIP-25 makes reactions portable. A like, emoji reaction or negative signal becomes a signed event that another client can count, show, mute or ignore.
Reactions look lightweight, but they shape ranking, reputation and community mood. If a client counts every reaction the same way without showing source, relay coverage or spam filters, the social signal becomes easy to game.
What changes when you actually use it
For you, NIP-25: Reactions 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 7, kind 17, draft, content, e, id 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-25: Reactions is compatibility discipline. Implement kind 7, kind 17, draft, content, e, id 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
Inspect kind 7, kind 17, draft, content, e, id, p, pubkey because these are the pieces most likely to surface as product behavior. Read it beside NIP-30, NIP-73 before treating it as isolated.
NIP-25: Reactions 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-25: Reactions is often indirect. Nobody complains about kind 7, kind 17, draft, content, e, id; 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-25: Reactions 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 7, kind 17, draft, content, e, id 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-25: Reactions 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-30, NIP-73 to see where the base contract ends and the product-specific promise begins.
Language that keeps the feature honest
Good product copy for NIP-25: Reactions 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-25: Reactions 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-25: Reactions with the visible product symptom, then trace it back to kind 7, kind 17, draft, content, e, id. 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: nips.nostr.com NIP-25 mirror, NIP-30 Custom Emoji, NIP-73 external IDs, Nostrbook kind 7. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-25 source is the anchor for exact wording, and NIP-25 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-25 mirror, NIP-30 Custom Emoji, NIP-73 external IDs. 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-25: Reactions: first the human promise, then kind 7, kind 17, draft, content, e, id, then the implementation record, then the real-world failure case. That order keeps NIP-25 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can two independent clients read the same
kind 7,kind 17,draft,contentwithout 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-30, NIP-73, changes the behavior once the base event leaves the happy path?
What to verify before you rely on it
- Find
kind 7,kind 17,draft,content,ein the official file and check where the UI exposes the same concept. - Read NIP-30, NIP-73 as context before treating NIP-25 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-25: Reactions in that order: Official NIP-25 source for the current wording; NIP-25 commit history for the change record; nips.nostr.com NIP-25 mirror, NIP-30 Custom Emoji, NIP-73 external IDs 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.
