NIP-11 for publishing server metadata (#51)

nips/11.md

@@ -0,0 +1,58 @@
+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.
+
+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.