← All NIPs

NIP-56

Reporting

DraftEvents

A kind 1984 report flags a profile, a note or a media file as objectionable, with a type such as spam, impersonation or malware. Anyone can read reports; clients and relays decide for themselves whether to act on them, typically trusting reports from people you follow.

Status
In use and still allowed to change.
Kinds
Tags
  • e
  • l
  • L
  • p
  • server
  • x
Last changed
Jun 13, 2026

Try it

Edit the form or the JSON: both stay in sync, the badge says whether the result is valid, and tapping any field explains it.

Examples
Valid 1 note

Not signed yet · Demo keys only. These personas' secret keys are public on purpose.

Form
Jan 1, 2025, 12:00 AM UTC

Content

Optional extra information from the reporter.

Tags

  1. e Optional

    The note being reported, if any.

  2. p Required

    The user being reported. Always required, even when reporting a note.

Add tag

How this NIP works

Step 1 of 5

Say what you are reporting

Always p-tag the user. Add an e tag for a specific note, or an x tag (plus e) for a media file.

In the course

See also

  • NIP-32 Labeling

    Labels (L and l tags) add structured categories to reports.

  • NIP-51 Lists

    Mute lists are the personal counterpart to public reports.

  • NIP-B7 Blossom

    Blossom servers host the blobs that x tags identify.

Specification

Specification text is quoted in English from the nostr-protocol/nips repository. Our explanations and the interface are translated. Source on GitHub at commit 0046368

Read the spec473 words, quoted from the repository at commit 0046368.

A report is a kind 1984 event that signals to users and relays that some referenced content is objectionable. The definition of objectionable is obviously subjective and all agents on the network (users, apps, relays, etc.) may consume and take action on them as they see fit.

The content MAY contain additional information submitted by the entity reporting the content.

Tags

The report event MUST include a p tag referencing the pubkey of the user you are reporting.

If reporting a note, an e tag MUST also be included referencing the note id.

A report type string MUST be included as the 3rd entry to the e, p or x tag being reported, which consists of the following report types:

  • nudity - depictions of nudity, porn, etc.
  • malware - virus, trojan horse, worm, robot, spyware, adware, back door, ransomware, rootkit, kidnapper, etc.
  • profanity - profanity, hateful speech, etc.
  • illegal - something which may be illegal in some jurisdiction
  • spam - spam
  • impersonation - someone pretending to be someone else
  • other - for reports that don't fit in the above categories

Some report tags only make sense for profile reports, such as impersonation.

  • x tags SHOULD be info hash of a blob which is intended to be report. when the x tag is represented client MUST include an e tag which is the id of the event that contains the mentioned blob. also, additionally these events can contain a server tag to point to media servers which may contain the mentioned media.

l and L tags MAY be also be used as defined in NIP-32 to support further qualification and querying.

Example events

{
  "kind": 1984,
  "tags": [
    ["p", "<pubkey>", "nudity"],
    ["L", "social.nos.ontology"],
    ["l", "NS-nud", "social.nos.ontology"]
  ],
  "content": "",
  // other fields...
}

{
  "kind": 1984,
  "tags": [
    ["e", "<eventId>", "illegal"],
    ["p", "<pubkey>"]
  ],
  "content": "He's insulting the king!",
  // other fields...
}

{
  "kind": 1984,
  "tags": [
    ["p", "<impersonator pubkey>", "impersonation"]
  ],
  "content": "Profile is impersonating nostr:<victim bech32 pubkey>",
  // other fields...
}

{
  "kind": 1984,
  "tags": [
    ["x", "<blob hash>", "malware"],
    ["e", "<event id which contains the blob on x tag>", "malware"],
    ["server", "https://you-may-find-the-blob-here.com/path-to-url.ext"]
  ],
  "content": "This file contains malware software in it.",
  // other fields...
}

Client behavior

Clients can use reports from friends to make moderation decisions if they choose to. For instance, if 3+ of your friends report a profile for nudity, clients can have an option to automatically blur photos from said account.

Relay behavior

It is not recommended that relays perform automatic moderation using reports, as they can be easily gamed. Admins could use reports from trusted moderators to takedown illegal or explicit content if the relay does not allow such things.