Merge branch 'nostr-protocol:master' into master

Author: RandyMcMillan

11.md

@@ -80,15 +80,14 @@ Extra Fields
 ### Server Limitations
 
 These are limitations imposed by the relay on clients. Your client
-should expect that requests which exceed these *practical* limitations
+should expect that requests exceed these *practical* limitations
 are rejected or fail immediately.
 
 ```jsonc
 {
   "limitation": {
     "max_message_length": 16384,
-    "max_subscriptions": 20,
-    "max_filters": 100,
+    "max_subscriptions": 300,
     "max_limit": 5000,
     "max_subid_length": 100,
     "max_event_tags": 100,
@@ -98,33 +97,30 @@ are rejected or fail immediately.
     "payment_required": true,
     "restricted_writes": true,
     "created_at_lower_limit": 31536000,
-    "created_at_upper_limit": 3
+    "created_at_upper_limit": 3,
+    "default_limit": 500
   },
   // other fields...
 }
 ```
 
-- `max_message_length`: this is the maximum number of bytes for incoming JSON that the relay
+- `max_message_length`: the maximum number of bytes for incoming JSON that the relay
 will attempt to decode and act upon. When you send large subscriptions, you will be
 limited by this value. It also effectively limits the maximum size of any event. Value is
-calculated from `[` to `]` and is after UTF-8 serialization (so some unicode characters
+calculated from `[` to `]` after UTF-8 serialization (so some unicode characters
 will cost 2-3 bytes). It is equal to the maximum size of the WebSocket message frame.
 
 - `max_subscriptions`: total number of subscriptions that may be
-active on a single websocket connection to this relay. It's possible
-that authenticated clients with a (paid) relationship to the relay
+active on a single websocket connection to this relay. Authenticated clients with a (paid) relationship to the relay
 may have higher limits.
 
-- `max_filters`: maximum number of filter values in each subscription.
-Must be one or higher.
-
 - `max_subid_length`: maximum length of subscription id as a string.
 
 - `max_limit`: the relay server will clamp each filter's `limit` value to this number.
 This means the client won't be able to get more than this number
 of events from a single subscription filter. This clamping is typically done silently
 by the relay, but with this number, you can know that there are additional results
-if you narrowed your filter's time range or other parameters.
+if you narrow your filter's time range or other parameters.
 
 - `max_event_tags`: in any event, this is the maximum number of elements in the `tags` list.
 
@@ -142,7 +138,7 @@ Even if set to False, authentication may be required for specific actions.
 
 - `payment_required`: this relay requires payment before a new connection may perform any action.
 
-- `restricted_writes`: this relay requires some kind of condition to be fulfilled in order to
+- `restricted_writes`: this relay requires some kind of condition to be fulfilled to
 accept events (not necessarily, but including `payment_required` and `min_pow_difficulty`).
 This should only be set to `true` when users are expected to know the relay policy before trying
 to write to it -- like belonging to a special pubkey-based whitelist or writing only events of
@@ -152,6 +148,8 @@ 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
@@ -212,7 +210,7 @@ flexibility is up to the client software.
 ```
 
 - `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.
+  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
@@ -237,7 +235,7 @@ To support this goal, relays MAY specify some of the following values.
 
 - `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.
+  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
@@ -276,49 +274,82 @@ Relays that require payments may want to expose their fee schedules.
 
 ### Examples
 
-As of 2 May 2023 the following command provided these results:
+As of 25 March 2025 the following command provided these results:
 
 ```bash
-$ curl -H "Accept: application/nostr+json" https://eden.nostr.land | jq
+curl -H "Accept: application/nostr+json" https://jellyfish.land | jq
 ```
 
 ```json
 {
-  "description": "nostr.land family of relays (us-or-01)",
-  "name": "nostr.land",
-  "pubkey": "52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd",
-  "software": "custom",
+  "name": "JellyFish",
+  "description": "Stay Immortal!",
+  "banner": "https://image.nostr.build/7fdefea2dec1f1ec25b8ce69362566c13b2b7f13f1726c2e4584f05f64f62496.jpg",
+  "pubkey": "bf2bee5281149c7c350f5d12ae32f514c7864ff10805182f4178538c2c421007",
+  "contact": "[email protected]",
+  "software": "https://github.com/dezh-tech/immortal",
   "supported_nips": [
     1,
-    2,
-    4,
     9,
     11,
-    12,
-    16,
-    20,
-    22,
-    28,
-    33,
-    40
+    13,
+    17,
+    40,
+    42,
+    59,
+    62,
+    70
   ],
-  "version": "1.0.1",
-  "limitation": {
-    "payment_required": true,
-    "max_message_length": 65535,
-    "max_event_tags": 2000,
-    "max_subscriptions": 20,
-    "auth_required": false
-  },
-  "payments_url": "https://eden.nostr.land",
+  "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": [],
   "fees": {
     "subscription": [
       {
-        "amount": 2500000,
-        "unit": "msats",
-        "period": 2592000
+        "amount": 3000,
+        "period": 2628003,
+        "unit": "sats"
+      },
+      {
+        "amount": 8000,
+        "period": 7884009,
+        "unit": "sats"
+      },
+      {
+        "amount": 15000,
+        "period": 15768018,
+        "unit": "sats"
+      },
+      {
+        "amount": 28000,
+        "period": 31536036,
+        "unit": "sats"
       }
     ]
   },
+  "limitation": {
+    "auth_required": false,
+    "max_message_length": 70000,
+    "max_subid_length": 256,
+    "max_subscriptions": 350,
+    "min_pow_difficulty": 0,
+    "payment_required": true,
+    "restricted_writes": true,
+    "max_event_tags": 2000,
+    "max_content_length": 70000,
+    "created_at_lower_limit": 0,
+    "created_at_upper_limit": 2147483647,
+    "default_limit": 500,
+    "max_limit": 5000
+  }
 }
 ```

65.md

@@ -6,11 +6,9 @@ Relay List Metadata
 
 `draft` `optional`
 
-Defines a replaceable event using `kind:10002` to advertise preferred relays for discovering a user's content and receiving fresh content from others.
+Defines a replaceable event using `kind:10002` to advertise relays where the user generally **writes** to and relays where the user generally **reads** mentions.
 
-The event MUST include a list of `r` tags with relay URIs and a `read` or `write` marker. Relays marked as `read` / `write` are called READ / WRITE relays, respectively. If the marker is omitted, the relay is used for both purposes.
-
-The `.content` is not used.
+The event MUST include a list of `r` tags with relay URLs as value and an optional `read` or `write` marker. If the marker is omitted, the relay is both **read** and **write**.
 
 ```jsonc
 {
@@ -26,45 +24,19 @@ The `.content` is not used.
 }
 ```
 
-This NIP doesn't fully replace relay lists that are designed to configure a client's usage of relays (such as `kind:3` style relay lists). Clients MAY use other relay lists in situations where a `kind:10002` relay list cannot be found.
-
-## When to Use Read and Write Relays
-
-When seeking events **from** a user, Clients SHOULD use the WRITE relays of the user's `kind:10002`.
-
-When seeking events **about** a user, where the user was tagged, Clients SHOULD use the READ relays of the user's `kind:10002`.
-
-When broadcasting an event, Clients SHOULD:
-
-- Broadcast the event to the WRITE relays of the author
-- Broadcast the event to all READ relays of each tagged user
-
-## Motivation
-
-The old model of using a fixed relay list per user centralizes in large relay operators: 
-
-  - Most users submit their posts to the same highly popular relays, aiming to achieve greater visibility among a broader audience
-  - Many users are pulling events from a large number of relays in order to get more data at the expense of duplication
-  - Events are being copied between relays, oftentimes to many different relays
-  
-This NIP allows Clients to connect directly with the most up-to-date relay set from each individual user, eliminating the need of broadcasting events to popular relays. 
-
-## Final Considerations
-
-1. Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays). 
+When downloading events **from** a user, clients SHOULD use the **write** relays of that user.
 
-2. Clients SHOULD spread an author's `kind:10002` event to as many relays as viable. 
+When downloading events **about** a user, where the user was tagged (mentioned), clients SHOULD use the user's **read** relays.
 
-3. `kind:10002` events should primarily be used to advertise the user's preferred relays to others. A user's own client may use other heuristics for selecting relays for fetching data.
+When publishing an event, clients SHOULD:
 
-4. DMs SHOULD only be broadcasted to the author's WRITE relays and to the receiver's READ relays to keep maximum privacy. 
+- Send the event to the **write** relays of the author
+- Send the event to all **read** relays of each tagged user
 
-5. If a relay signals support for this NIP in their [NIP-11](11.md) document that means they're willing to accept kind 10002 events from a broad range of users, not only their paying customers or whitelisted group.
+### Size
 
-6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
+Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays of each category).
 
-7. When publishing to a relay, clients SHOULD ensure the user's `kind 10002` is also available on that relay. Relays SHOULD accept and serve `kind 10002` notes for any pubkey whose notes they store. Relays MAY scrape the network for missing `kind 10002` events. The goal here is that for any note served from a relay the user can also request the author's relay selections as a way of bootstrapping further context discovery.
+### Discoverability
 
-## Related articles
-- [Outbox model](https://mikedilger.com/gossip-model/)
-- [What is the Outbox Model?](https://habla.news/u/[email protected]/8YjqXm4SKY-TauwjOfLXS)
+Clients SHOULD spread an author's `kind:10002` event to as many relays as viable, paying attention to relays that, at any moment, serve naturally as well-known public indexers for these relay lists (where most other clients and users are connecting to in order to publish and fetch those).