Shrink NIP-65 so it is clearer ()

Co-authored-by: Vitor Pamplona <vitor@vitorpamplona.com>
This commit is contained in:
fiatjaf_ 2025-04-15 18:07:49 -03:00 committed by GitHub
parent 611b635186
commit 45f6d598a1
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

50
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 downloading events **from** a user, clients SHOULD use the **write** relays of that user.
## When to Use Read and Write Relays
When downloading events **about** a user, where the user was tagged (mentioned), clients SHOULD use the user's **read** relays.
When seeking events **from** a user, Clients SHOULD use the WRITE relays of the user's `kind:10002`.
When publishing an event, clients SHOULD:
When seeking events **about** a user, where the user was tagged, Clients SHOULD use the READ relays of the user's `kind:10002`.
- Send the event to the **write** relays of the author
- Send the event to all **read** relays of each tagged user
When broadcasting an event, Clients SHOULD:
### Size
- Broadcast the event to the WRITE relays of the author
- Broadcast the event to all READ relays of each tagged user
Clients SHOULD guide users to keep `kind:10002` lists small (2-4 relays of each category).
## Motivation
### Discoverability
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).
2. Clients SHOULD spread an author's `kind:10002` event to as many relays as viable.
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.
4. DMs SHOULD only be broadcasted to the author's WRITE relays and to the receiver's READ relays to keep maximum privacy.
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.
6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
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.
## Related articles
- [Outbox model](https://mikedilger.com/gossip-model/)
- [What is the Outbox Model?](https://habla.news/u/hodlbod@coracle.social/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).