From 10dc301eb803d553625d80507182cf69c603adae Mon Sep 17 00:00:00 2001
From: Jon Staab <shtaab@gmail.com>
Date: Fri, 7 Feb 2025 15:54:34 -0800
Subject: [PATCH] Add self to NIP 11

---
 11.md | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/11.md b/11.md
index 8af4f313..142c43a4 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
   "banner": <a link to an image (e.g. in .jpg, or .png format)>,
   "icon": <a link to an icon (e.g. in .jpg, or .png format>,
   "pubkey": <administrative contact pubkey>,
+  "self": <relay's own pubkey>,
   "contact": <administrative alternate contact>,
   "supported_nips": <a list of NIP numbers supported by the relay>,
   "software": <string identifying relay software URL>,
@@ -58,6 +59,10 @@ An administrative contact may be listed with a `pubkey`, in the same format as N
 
 Relay operators have no obligation to respond to direct messages.
 
+### Self
+
+A relay MAY maintain an identity independent from its administrator using the `self` field, which MUST be a 32-byte hex public key. This allows relays to respond to requests with events published either in advance or on demand by their own key.
+
 ### 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.