3.1 KiB
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 NIP
s 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.