Nostrbook

Appearance

Kind 10006: Blocked Relays ​

Overview ​

Blocked Relays events (kind 10006) allow users to maintain a list of relays that their clients should never connect to. This standard replaceable event kind serves as a blacklist of relays the user wants to avoid, whether for privacy concerns, content issues, performance problems, or other reasons. By publishing this list, users can synchronize their relay blocking preferences across devices and client applications.

Specification ​

PropertyValue
Kind Number10006
Event RangeReplaceable
Defined inNIP-51

Content Format ​

The content field can contain encrypted private blocked relays using NIP-04 encryption. The encrypted content follows the same structure as the public tags but is only visible to the creator. This allows users to have both public blocked relays (in tags) and private ones (encrypted in content).

Schema ​

For encrypted private blocked relays:

json
"content": "<NIP-04 encrypted JSON array of tags>"

The encrypted content, when decrypted, would reveal a JSON array of tags:

json
[
  ["relay", "wss://blocked-relay.example.com"]
]

Tags ​

Tag NameDescriptionFormatRequired
relayURL of a relay to block["relay", "<relay-url>"]Yes

Client Behavior ​

Clients should:

  1. Check this list when determining which relays to connect to
  2. Never establish connections to relays listed in this event
  3. Provide an interface for users to add or remove relays from their blocked list
  4. Handle both public (in tags) and private (encrypted in content) blocked relay entries
  5. Ensure that blocked relays are not included in any automatic relay discovery mechanisms
  6. When processing encrypted blocked relays, decrypt using NIP-04 and the user's keys
  7. Maintain the chronological order of blocked relays, with newest additions at the end
  8. Consider providing information about why certain relays were blocked (e.g., with additional custom tags)
  9. Apply the blocked relays list immediately when connecting to the network

Relay Behavior ​

Relays should:

  1. Handle kind 10006 events as normal replaceable events
  2. Store these events to allow clients to retrieve the user's blocked relays list
  3. Not attempt to interpret or enforce relay blocking (this is client-side functionality)

Use Cases ​

  • Avoiding relays with unwanted content or moderation policies
  • Blocking relays with poor performance or reliability
  • Preventing connection to relays with privacy concerns
  • Managing relay connections across multiple devices
  • Avoiding relays that are known to have malicious behavior
  • Protecting user privacy by avoiding certain relays
  • Creating client-specific relay filtering policies

Example ​

json
{
  "id": "82341f882b6eabcd2ba7f1ef90aad961cf074af15c02ce3d6f3a961f5e1d3ce4",
  "pubkey": "854043ae8f1f97430ca8c1f1a090bdde6488bd5115c7a45307a2a212750ae4cb",
  "created_at": 1699597889,
  "kind": 10006,
  "tags": [
    ["relay", "wss://bad-actor-relay.example.com"],
    ["relay", "wss://privacy-violating-relay.example.org"],
    ["relay", "wss://unreliable-relay.example.net"]
  ],
  "content": "TJob1dQrf2ndsmdbeGU+05HT5GMnBSx3fx8QdDY/g3NvCa7klfzgaQCmRZuo1d3WQjHDOjzS==?iv=S3rFeFr1gsYqmQA7bNnNTQ==",
  "sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
}

References ​

Notes ​

  • Blocked Relays list is one of several standard list types defined in NIP-51
  • Users can only have one blocked relays list (since it's a replaceable event)
  • Relay URLs should follow the format wss://hostname[:port] or ws://hostname[:port]
  • This list doesn't prevent other users from finding the user's content on these relays
  • The blocking is only enforced at the client level; relays are unaware of being blocked
  • For maximum privacy, users may prefer to keep their blocked relay list encrypted
  • Clients should periodically check for updates to this list when managing connections