Nostrbook

Appearance

Kind 10007: Search Relays ​

Overview ​

Search Relays events (kind 10007) allow users to specify which relays they prefer for performing search operations. This standard replaceable event kind identifies relays with good search capabilities or comprehensive content indexes. By publishing this list, users can optimize their search experience and help clients know which relays to prioritize when executing search queries.

Specification ​

PropertyValue
Kind Number10007
Event RangeReplaceable
Defined inNIP-51

Content Format ​

The content field can contain encrypted private search 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 search relays (in tags) and private ones (encrypted in content).

Schema ​

For encrypted private search 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://search-relay.example.com"]
]

Tags ​

Tag NameDescriptionFormatRequired
relayURL of a relay recommended for search["relay", "<relay-url>"]Yes

Client Behavior ​

Clients should:

  1. Use this list when performing search operations
  2. Prioritize these relays for queries involving text search, hashtag search, or content discovery
  3. Provide an interface for users to add or remove relays from their search relays list
  4. Handle both public (in tags) and private (encrypted in content) search relay entries
  5. When processing encrypted search relays, decrypt using NIP-04 and the user's keys
  6. Maintain the chronological order of search relays, with newest additions at the end
  7. Potentially weight search results by the order of relays in this list
  8. Consider connecting to these relays specifically when a search is initiated
  9. Disconnect from search-only relays when not actively searching to reduce connection load

Relay Behavior ​

Relays should:

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

Use Cases ​

  • Optimizing search performance by targeting high-quality relay indexes
  • Improving search result quality
  • Reducing query load on regular relays
  • Making specialized search relays discoverable
  • Separating general browsing from search operations
  • Sharing knowledge of good search relays with others
  • Creating a collection of relays with different search specializations

Example ​

json
{
  "id": "7dcdd8e145c23d5e13c66cb56bd8af2208a156ecefc08a9686764611e4393766",
  "pubkey": "854043ae8f1f97430ca8c1f1a090bdde6488bd5115c7a45307a2a212750ae4cb",
  "created_at": 1699597889,
  "kind": 10007,
  "tags": [
    ["relay", "wss://relay.nostr.band"],
    ["relay", "wss://search.nostr.wine"],
    ["relay", "wss://relay.nostrsearch.com"]
  ],
  "content": "TJob1dQrf2ndsmdbeGU+05HT5GMnBSx3fx8QdDY/g3NvCa7klfzgaQCmRZuo1d3WQj==?iv=S3rFeFr1gsYqmQA7bNnNTQ==",
  "sig": "a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd"
}

References ​

Notes ​

  • Search Relays list is one of several standard list types defined in NIP-51
  • Users can only have one search 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 guarantee that relays have search functionality, but suggests they do
  • The ordering of relay tags may indicate search preference or priority
  • Search relays typically have different characteristics than general-purpose relays:
    • More comprehensive event indexing
    • Text search capabilities
    • Advanced filtering options
    • Higher resource requirements
  • Clients might implement different connection strategies for search relays