NIP-56: Reporting
Open relays still need signals about bad content
Nostr does not have one moderation department. That does not mean users, clients and relays have to be blind. NIP-56 defines a report event that can point at a pubkey, note or blob and say why the reporter considers it objectionable.
The word considers is important. The official source says objectionable is subjective. A report is a signal, not a verdict. Different clients, users and relays may consume reports differently or ignore them entirely.
That makes NIP-56 a moderation primitive rather than a policy. It lets communities build trust lists, friend-based filters, relay admin tools and user warnings without pretending the protocol itself knows what needs to be removed.
Kind 1984 and report-type tags
A report is kind 1984. It must include a p tag for the reported pubkey. If reporting a note, it also includes an e tag. For media blobs, the newer x tag can point at a blob hash, accompanied by the event that contains the blob and an optional server tag.
The report type appears as the third entry of the reported e, p or x tag. The standard names nudity, malware, profanity, illegal, spam, impersonation and other. NIP-32 label tags may further qualify reports.
The examples show profile reports, event reports and malware blob reports. That scope is useful because abuse is not only text. It can be identity impersonation, spam accounts, illegal media or malicious files.
Reports grew from social moderation to digital-threat signaling
William Casarin added the visible reporting NIP in February 2023. Jonathan Staab later connected reporting with NIP-32 labeling. In 2024, Matthew Lorentz updated the description and added category language, and Lucas Nuic added language around decentralized reporting of digital threats such as malware.
In January 2025, k added the x tag to report blobs. That broadened the standard from people and notes to media and file safety, which matters as Blossom, file metadata and media storage became more important.
The history shows NIP-56 moving from social complaint to broader safety signal.
Reports are useful only when trust is explicit
A client can use reports from friends, followed moderators or trusted communities to blur, hide or warn. A relay admin can use reports from trusted moderators to investigate content that violates relay policy. The source warns against automatic relay moderation because reports can be gamed.
Good implementation therefore needs provenance: who reported, what they reported, what category they used and whether the viewer trusts that reporter. A pile of anonymous reports is not automatically truth.
NIP-56 works best with NIP-32 labels, NIP-72 communities and relay-level policies. It supplies the report event; social trust decides the action.
Reports can be weaponized
Any public reporting system can be gamed by brigading, false reports or political pressure. NIP-56 does not solve that. It deliberately leaves action to users, apps and relays.
There is also privacy risk for reporters. A public report reveals that a user saw something and objected to it. Clients may need private or community-scoped reporting flows around the public primitive.
Read NIP-56 in the wild
NIP-56 gives reports a portable form. Spam, impersonation, malware and abuse need signals that can travel across clients and relays instead of disappearing inside one company's moderation queue.
Reports are also attack surfaces. A signed report proves who complained, not that the complaint is fair. Show reporter, target, reason, trust context and action separately.
What changes when you actually use it
For you, NIP-56: Reporting is felt when someone makes a claim about content, people, trust, status or community behavior. Reports, labels, badges, assertions and polls can help you navigate an open network, but they can also become quiet authority. Read NIP-32 so you see who speaks, what is targeted and how much weight the claim deserves.
What changes for builders and operators
For builders and moderators, NIP-56: Reporting means preventing claims from becoming invisible law. Show issuer, target, reason, timestamp, evidence and conflict. Let people understand why a label, report, badge or assertion appears before it changes what they can see.
What the official file makes concrete
Inspect kind 1984, content, p, e, report type, malware because these are the pieces most likely to surface as product behavior. Read it beside NIP-32 before treating it as isolated.
NIP-56: Reporting is a claim layer. Reports, labels, badges, assertions and polls only help when issuer, target and scope stay visible.
Where it breaks
The failure mode in NIP-56: Reporting is authority theater. A report, label, badge, assertion or poll can look official because it is signed and rendered cleanly. The signature proves the issuer, not the fairness or accuracy of the claim.
Where this appears outside the markdown
In the ecosystem, NIP-56: Reporting belongs to the social safety and coordination layer. It can help people filter noise, recognize contribution, report abuse, run polls or make assertions. It can also concentrate influence quietly if the issuer disappears behind the label. The hub has to preserve that tension instead of selling governance as solved.
The nearby-standard trap
The nearby-standard trap in NIP-56: Reporting is treating every signed claim as a moderation decision. A label, report, badge, assertion or poll can inform judgment without becoming policy. Read NIP-32 and keep issuer, target and consequence separate.
Language that keeps the feature honest
Good product copy for NIP-56: Reporting names the claimant. It says who reported, labeled, awarded, asserted, voted or counted, and it leaves room for conflict. That is how a safety feature avoids becoming invisible authority.
What this page does not promise
NIP-56: Reporting does not make a community decision neutral. Signed reports, labels, badges, assertions and polls can improve safety or discovery, but they still come from people, services or institutions with incentives. The standard helps expose the claim. It does not make the claim fair, complete or universally binding.
Read it as a field test
Start NIP-56: Reporting with the claimant. A label, report, badge, assertion or poll has meaning only when issuer, target, reason and consequence remain visible. The article needs to preserve that social context because signed data can still be biased, stale or disputed.
Where the standard earns trust
The source links give you places to test the interpretation in public: NIP-32 Labeling, NIP-72 Moderated Communities, PR #1669, Nostr.how. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-56 source is the anchor for exact wording, and NIP-56 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-32 Labeling, NIP-72 Moderated Communities, PR #1669. 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-56: Reporting: first the human promise, then kind 1984, content, p, e, report type, malware, then the implementation record, then the real-world failure case. That order keeps NIP-56 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who issued the claim, label, badge, report, assertion or poll, and what exactly is the target?
- Can you see evidence, conflicts, expiry and scope before the claim changes what you see?
- Does the design leave room for disagreement instead of hiding authority behind a clean badge?
What to verify before you rely on it
- Find
kind 1984,content,p,e,report typein the official file and check where the UI exposes the same concept. - Read NIP-32 as context before treating NIP-56 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-56: Reporting in that order: Official NIP-56 source for the current wording; NIP-56 commit history for the change record; NIP-32 Labeling, NIP-72 Moderated Communities, PR #1669 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.
