Merge nip44-big-payloads into bigger-nip44bigger-nip44

1 files changed, 69 insertions, 193 deletions

diff --git a/11.md b/11.md
index 8229bd4..d1acab7 100644
--- a/11.md
+++ b/11.md
@@ -4,9 +4,9 @@ NIP-11
 Relay Information Document
 --------------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
-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.
+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.
 
@@ -17,14 +17,12 @@ 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>,
-  "version": <string version identifier>
-  "privacy_policy": <a link to a text file describing the relay's privacy policy>,
-  "terms_of_service": <a link to a text file describing the relay's term of service>,
-
-
+  "version": <string version identifier>,
+  "terms_of_service": <a link to a text file describing the relay's term of service>
 }
 ```
 
@@ -35,11 +33,11 @@ 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.
+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.
+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.
 
 ### Banner
 
@@ -58,36 +56,34 @@ Icon is a compact visual representation of the relay for use in UI with limited
 
 ### 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-17](17.md)) to a system administrator.  Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance.
+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-17](17.md)) 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.
 
+### 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.
+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.
+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.
+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.
-
-### Privacy Policy
-
-The relay owner/admin MAY choose to link to a privacy policy document, which describes how the relay utilizes user data. Data collection, data usage, data retention, monetization of data, and third party data sharing SHOULD be included.
+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.
 
 ### Terms of Service
 
 The relay owner/admin MAY choose to link to a terms of service document.
 
-
-
 Extra Fields
 ------------
 
@@ -162,113 +158,7 @@ a specific niche kind or content. Normal anti-spam heuristics, for example, do n
 
 - `created_at_upper_limit`: 'created_at' upper limit
 
-- `default_limit`: The maximum returned events if you send a filter with the limit set to 0.
-
-### Event Retention
-
-There may be a cost associated with storing data forever, so relays
-may wish to state retention times. The values stated here are defaults
-for unauthenticated users and visitors. Paid users would likely have
-other policies.
-
-Retention times are given in seconds, with `null` indicating infinity.
-If zero is provided, this means the event will not be stored at
-all, and preferably an error will be provided when those are received.
-
-```jsonc
-{
-  "retention": [
-    {"kinds": [0, 1, [5, 7], [40, 49]], "time": 3600},
-    {"kinds": [[40000, 49999]], "time": 100},
-    {"kinds": [[30000, 39999]], "count": 1000},
-    {"time": 3600, "count": 10000}
-  ],
-  // other fields...
-}
-```
-
-`retention` is a list of specifications: each will apply to either all kinds, or
-a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive
-start and end values. Events of indicated kind (or all) are then limited to a `count`
-and/or time period.
-
-It is possible to effectively blacklist Nostr-based protocols that rely on
-a specific `kind` number, by giving a retention time of zero for those `kind` values.
-While that is unfortunate, it does allow clients to discover servers that will
-support their protocol quickly via a single HTTP fetch.
-
-There is no need to specify retention times for _ephemeral events_ since they are not retained.
-
-### Content Limitations
-
-Some relays may be governed by the arbitrary laws of a nation state. This
-may limit what content can be stored in clear-text on those relays. All
-clients are encouraged to use encryption to work around this limitation.
-
-It is not possible to describe the limitations of each country's laws
-and policies which themselves are typically vague and constantly shifting.
-
-Therefore, this field allows the relay operator to indicate which
-countries' laws might end up being enforced on them, and then
-indirectly on their users' content.
-
-Users should be able to avoid relays in countries they don't like,
-and/or select relays in more favorable zones. Exposing this
-flexibility is up to the client software.
-
-```jsonc
-{
-  "relay_countries": [ "CA", "US" ],
-  // other fields...
-}
-```
-
-- `relay_countries`: a list of two-level ISO country codes (ISO 3166-1 alpha-2)  whose
-  laws and policies may affect this relay. `EU` may be used for European Union countries. A `*` can be used for global relays.
-
-Remember that a relay may be hosted in a country which is not the
-country of the legal entities who own the relay, so it's very
-likely a number of countries are involved.
-
-
-### Community Preferences
-
-For public text notes at least, a relay may try to foster a
-local community. This would encourage users to follow the global
-feed on that relay, in addition to their usual individual follows.
-To support this goal, relays MAY specify some of the following values.
-
-```jsonc
-{
-  "language_tags": ["en", "en-419"],
-  "tags": ["sfw-only", "bitcoin-only", "anime"],
-  "posting_policy": "https://example.com/posting-policy.html",
-  // other fields...
-}
-```
-
-- `language_tags` is an ordered list
-  of [IETF language tags](https://en.wikipedia.org/wiki/IETF_language_tag) indicating
-  the major languages spoken on the relay. A `*` can be used for global relays.
-
-- `tags` is a list of limitations on the topics to be discussed.
-  For example `sfw-only` indicates that only "Safe For Work" content
-  is encouraged on this relay. This relies on assumptions of what the
-  "work" "community" feels "safe" talking about. In time, a common
-  set of tags may emerge that allow users to find relays that suit
-  their needs, and client software will be able to parse these tags easily.
-  The `bitcoin-only` tag indicates that any *altcoin*, *"crypto"* or *blockchain*
-  comments will be ridiculed without mercy.
-
-- `posting_policy` is a link to a human-readable page which specifies the
-  community policies for the relay. In cases where `sfw-only` is True, it's
-  important to link to a page which gets into the specifics of your posting policy.
-
-The `description` field should be used to describe your community
-goals and values, in brief. The `posting_policy` is for additional
-detail and legal terms. Use the `tags` field to signify limitations
-on content, or topics to be discussed, which could be machine
-processed by appropriate client software.
+- `default_limit`: The maximum returned events if you send a filter without a `limit`.
 
 ### Pay-to-Relay
 
@@ -288,82 +178,68 @@ Relays that require payments may want to expose their fee schedules.
 
 ### Examples
 
-As of 25 March 2025 the following command provided these results:
-
-```bash
-curl -H "Accept: application/nostr+json" https://jellyfish.land | jq
-```
-
-```json
+```yaml
+~> curl -H "Accept: application/nostr+json" https://nostr.wine | jq
 {
-  "name": "JellyFish",
-  "description": "Stay Immortal!",
-  "banner": "https://image.nostr.build/7fdefea2dec1f1ec25b8ce69362566c13b2b7f13f1726c2e4584f05f64f62496.jpg",
-  "pubkey": "bf2bee5281149c7c350f5d12ae32f514c7864ff10805182f4178538c2c421007",
-  "contact": "hi@dezh.tech",
-  "software": "https://github.com/dezh-tech/immortal",
-  "supported_nips": [
-    1,
-    9,
-    11,
-    13,
-    17,
-    40,
-    42,
-    59,
-    62,
-    70
-  ],
-  "version": "immortal - 0.0.9",
-  "relay_countries": [
-    "*"
-  ],
-  "language_tags": [
-    "*"
-  ],
-  "tags": [],
-  "posting_policy": "https://jellyfish.land/tos.txt",
-  "payments_url": "https://jellyfish.land/relay",
-  "icon": "https://image.nostr.build/2547e9ec4b23589e09bc7071e0806c3d4293f76284c58ff331a64bce978aaee8.jpg",
-  "retention": [],
+  "contact": "wino@nostr.wine",
+  "description": "A paid nostr relay for wine enthusiasts and everyone else.",
   "fees": {
-    "subscription": [
-      {
-        "amount": 3000,
-        "period": 2628003,
-        "unit": "sats"
-      },
+    "admission": [
       {
-        "amount": 8000,
-        "period": 7884009,
-        "unit": "sats"
-      },
-      {
-        "amount": 15000,
-        "period": 15768018,
-        "unit": "sats"
-      },
-      {
-        "amount": 28000,
-        "period": 31536036,
-        "unit": "sats"
+        "amount": 18888000,
+        "unit": "msats"
       }
     ]
   },
+  "icon": "https://image.nostr.build/30acdce4a81926f386622a07343228ae99fa68d012d54c538c0b2129dffe400c.png",
   "limitation": {
     "auth_required": false,
-    "max_message_length": 70000,
-    "max_subid_length": 256,
-    "max_subscriptions": 350,
+    "created_at_lower_limit": 94608000,
+    "created_at_upper_limit": 300,
+    "max_event_tags": 4000,
+    "max_limit": 1000,
+    "max_message_length": 524288,
+    "max_subid_length": 71,
+    "max_subscriptions": 50,
     "min_pow_difficulty": 0,
     "payment_required": true,
-    "restricted_writes": true,
+    "restricted_writes": true
+  },
+  "name": "nostr.wine",
+  "payments_url": "https://nostr.wine/invoices",
+  "pubkey": "4918eb332a41b71ba9a74b1dc64276cfff592e55107b93baae38af3520e55975",
+  "software": "https://nostr.wine",
+  "supported_nips": [ 1, 2, 4, 9, 11, 40, 42, 50, 70, 77 ],
+  "terms_of_service": "https://nostr.wine/terms",
+  "version": "0.3.3"
+}
+
+~> curl -H "Accept: application/nostr+json" https://nostr.land | jq
+{
+  "description": "[✨ NFDB] nostr.land family of relays (fi-01 [tiger])",
+  "name": "[✨ NFDB] nostr.land",
+  "pubkey": "52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd",
+  "software": "NFDB",
+  "icon": "https://i.nostr.build/b3thno790aodH8lE.jpg",
+  "supported_nips": [ 1, 2, 4, 8, 9, 10, 11, 13, 14, 15, 16, 17, 18, 19, 21, 22, 23, 24, 25, 27, 28, 30, 31, 32, 34, 35, 36, 37, 38, 39, 40, 42, 44, 46, 47, 48, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 64, 65, 68, 69, 71, 72, 73, 75, 78, 84, 88, 89, 90, 92, 99 ],
+  "version": "1.0.0",
+  "limitation": {
+    "payment_required": true,
+    "max_message_length": 65535,
     "max_event_tags": 2000,
-    "max_content_length": 70000,
-    "created_at_lower_limit": 0,
-    "created_at_upper_limit": 2147483647,
-    "default_limit": 500,
-    "max_limit": 5000
-  }
+    "max_subscriptions": 200,
+    "auth_required": false
+  },
+  "payments_url": "https://nostr.land",
+  "fees": {
+    "subscription": [
+      {
+        "amount": 4000000,
+        "unit": "msats",
+        "period": 2592000
+      }
+    ]
+  },
+  "terms_of_service": "https://nostr.land/terms"
 }
 ```