From cf7615fe999181c85f3ca17a649f47aabb309755 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Wed, 15 Feb 2023 11:22:00 -0600 Subject: [PATCH] Update NIP 11 to support relay extensions --- 11.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/11.md b/11.md index 2b268239a..957a3a1f8 100644 --- a/11.md +++ b/11.md @@ -17,6 +17,7 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application pubkey: , contact: , supported_nips: , + extensions: software: , version: } @@ -49,6 +50,10 @@ An alternative contact may be listed under the `contact` field as well, with the 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. +### Extensions ### + +Some NIPs may be more burdensome than others for relays to implement. Relays may advertise support for these NIPs as `extensions` by advertising other relays that support those NIPs for some or all of the given relay's events. For example, if a relay that functioned as a read replica wanted to advertise support for NIP 42 on the master relay it follows, it would set its `extensions` key to `[["NIP-42", "wss://my-master.example.com"]]`. + ### Software ### The relay server implementation MAY be provided in the `software` attribute. If present, this MUST be a URL to the project's homepage.