mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-05-12 15:49:57 -04:00
Shrink NIP-65 so it is clearer (#1879)
Co-authored-by: Vitor Pamplona <vitor@vitorpamplona.com>
This commit is contained in:
parent
611b635186
commit
45f6d598a1
50
65.md
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).
|
||||
|
Loading…
x
Reference in New Issue
Block a user