mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-09 22:09:06 -05:00
59 lines
3.1 KiB
Markdown
59 lines
3.1 KiB
Markdown
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.
|
|
|
|
```json
|
|
{
|
|
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.
|