nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-09 22:09:06 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

More explicit explanation of the meaning of read and write relays

Browse Source
This commit is contained in:
Mike Dilger 2023-02-20 09:28:39 +13:00 committed by fiatjaf_
parent 6849f3bdf4
commit 524caa3856
1 changed files with 11 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
65.md
View File

@ -10,20 +10,26 @@ A special replaceable event meaning "Relay List Metadata" is defined as an event
The primary purpose of this relay list is to advertise to others, not for configuring one's client.
The content is not used and SHOULD be blank.
The content is not used and SHOULD be an empty string.
The `r` tags can have a second parameter as either `read` or `write`. If it is omitted, it means the author both reads from and writes to that relay.
The `r` tags can have a second parameter as either `read` or `write`. If it is omitted, it means the author uses the relay for both purposes.
Clients SHOULD, as with all replaceable events, use only the most recent kind-10002 event they can find.
### The meaning of read and write
If an author advertises a write relay in a kind `10002` event, that means that feed-related events created by the author, which the author wants their followers to see, will be posted there. Normally these would be kind-1 Text Note events, but are not limited as such.
Write relays are for events that are intended for anybody (e.g. your followers). Read relays are for events that address a particular person.
Clients SHOULD write feed-related events created by their user to their user's write relays.
Clients SHOULD read feed-related events created by another from at least some of that other person's write relays. Explicitly, they SHOULD NOT expect them to be available at their user's read relays. It SHOULD NOT be presumed that the user's read relays coincide with the write relays of the people the user follows.
Clients SHOULD read events that tag their user from their user's read relays.
Clients SHOULD write events that tag a person to at least some of that person's read relays. Explicitly, they SHOULD NOT expect that person will pick them up from their user's write relays. It SHOULD NOT be presumed that the user's write relays coincide with the read relays of the person being tagged.
Clients SHOULD presume that if their user has a pubkey in their ContactList (kind 3) that it is because they wish to see that author's feed-related events. But clients MAY presume otherwise.
If an author advertises a read relay in a kind `10002` event, that means that the author may be subscribed to events that tag them on such relays. Clients SHOULD publish events that tag someone on at least some of the read relays of the person being tagged.
### Motivation
There is a common nostr use case where users wish to follow the content produced by other users. This is evidenced by the implicit meaning of the Contact List in [NIP-02](02.md)