NIP-11

Relay Information Document

draft optional author:scsibug

Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay's websocket.

When a relay receives an HTTP(s) request with an Accept header of application/nostr+json to a URI supporting WebSocket upgrades, they SHOULD return a document with the following structure.

{
  name: <string identifying relay>,
  description: <string with detailed information>,
  pubkey: <administrative contact pubkey>,
  contact: <administrative alternate contact>,
  supported_nips: <a list of NIP numbers supported by the relay>,
  software: <string identifying relay software URL>,
  version: <string version identifier>
}

Any field may be omitted, and clients MUST ignore any additional fields they do not understand. Relays MUST accept CORS requests by sending Access-Control-Allow-Origin, Access-Control-Allow-Headers, and Access-Control-Allow-Methods headers.

Field Descriptions

Name

A relay may select a name for use in client software. This is a string, and SHOULD be less than 30 characters to avoid client truncation.

Description

Detailed plain-text information about the relay may be contained in the description string. It is recommended that this contain no markup, formatting or line breaks for word wrapping, and simply use double newline characters to separate paragraphs. There are no limitations on length.

Pubkey

An administrative contact may be listed with a pubkey, in the same format as Nostr events (32-byte hex for a secp256k1 public key). If a contact is listed, this provides clients with a recommended address to send encrypted direct messages (See NIP-04) to a system administrator. Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance.

Relay operators have no obligation to respond to direct messages.

Contact

An alternative contact may be listed under the contact field as well, with the same purpose as pubkey. Use of a Nostr public key and direct message SHOULD be preferred over this. Contents of this field SHOULD be a URI, using schemes such as mailto or https to provide users with a means of contact.

Supported NIPs

As the Nostr protocol evolves, some functionality may only be available by relays that implement a specific NIP. This field is an array of the integer identifiers of NIPs that are implemented in the relay. Examples would include 1, for "NIP-01" and 9, for "NIP-09". Client-side NIPs SHOULD NOT be advertised, and can be ignored by clients.

Software

The relay server implementation MAY be provided in the software attribute. If present, this MUST be a URL to the project's homepage.

Version

The relay MAY choose to publish its software version as a string attribute. The string format is defined by the relay implementation. It is recommended this be a version number or commit identifier.

3.1 KiB Raw Blame History