nips/56.md

NIP-56

Reporting

optional

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.

Domain Protection and Link Safety

This extension to NIP-56 defines standards for domain protection and link safety in Nostr clients.

Motivation

To protect users from potentially malicious links and unwanted content while maintaining the decentralized nature of Nostr.

Specification

Domain List Event

A kind 10099 replaceable event for storing user domain preferences:

{
  "kind": 10099,
  "content": "",
  "tags": [
    ["d", "domain_lists"], // identifier 
    ["white", "nostr.build"],
    ["white", "void.cat"],
    ["black", "malicious-site.net"],
    ["black", "scam-domain.com"]
    ["unknown", "ask"]  // Options: "load" | "block" | "ask"
  ]
}

Report Event Extension

Extend kind 1984 events to include domain reporting:

{
  "kind": 1984,
  "tags": [
    ["u", "https://malicious-site.net", "malware"],
    ["L", "security.domain.safety"],
    ["l", "NS-mal", "security.domain.safety"]
  ],
  "content": "Domain distributes malware",
}

Additional Report Types

Add the following report types for domains:

• ip_grab - Sites attempting to collect IP addresses
• redirect - Unexpected redirects to other domains
• nsfw_content - Adult or explicit content
• phishing - Fraudulent sites imitating legitimate services

Client Implementation

Domain List Management

1. Clients MUST store user domain preferences in kind 10099 events
2. Clients SHOULD provide UI for managing white/blacklisted domains
3. Clients MAY implement an "ask" list for domains requiring user approval

Link Processing

1. Clients MUST check all links against user domain lists
2. For whitelisted domains:
   • Load content automatically
   • Display domain safety indicator
3. For blacklisted domains:
   • Display link as plain text only
   • Show warning about blocked status
   • Provide override option with clear warning
4. For unknown domains:
   • Display link with neutral indicator
   • Optionally require user confirmation before loading
   • Provide quick actions to add to white/blacklist

Report Aggregation

1. Clients SHOULD track domain report counts from followed users
2. Clients MAY use report thresholds to suggest domain blocking
3. Clients SHOULD cache domain reports for performance

Relay Behavior

1. Relays SHOULD accept and store kind 10099 events
2. Relays MAY maintain aggregated domain report statistics
3. Relays MUST NOT automatically block domains based on reports