mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-13 19:06:24 +00:00
60 lines
2.9 KiB
Markdown
60 lines
2.9 KiB
Markdown
|
NIP-65
|
||
|
|
======
|
||
|
|
|
||
|
|
Feed Advertisements
|
||
|
|
-------------------
|
||
|
|
|
||
|
|
`draft` `optional` `author:mikedilger`
|
||
|
|
|
||
|
|
A special replaceable event meaning "Feed Advertisement" is defined as an event with kind `10002` having a list of `r` tags, one for each relay the author posts their outgoing "feed" to.
|
||
|
|
|
||
|
|
The content is not used.
|
||
|
|
|
||
|
|
A feed consists of events that the author posts and wishes for their followers to "follow". Normally these would be kind-1 Text Note events but is not limited as such.
|
||
|
|
|
||
|
|
Clients SHOULD, as with all replaceable events, use only the most recent kind-10002 event they can find.
|
||
|
|
|
||
|
|
Clients SHOULD presume that if their user has a pubkey in their ContactList (kind 3) that it is because they wish to see this author's "feed" events. But clients MAY presume otherwise.
|
||
|
|
|
||
|
|
Clients SHOULD interpret these Feed Advertisements as being the best relays to source the "feed" events from the author of the feed advertisement.
|
||
|
|
|
||
|
|
### 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)
|
||
|
|
|
||
|
|
Because users don't often share the same sets of relays, ad-hoc solutions have arisen to get that content, but these solutions negatively impact scalability and decentralization:
|
||
|
|
|
||
|
|
- Most people are sending their posts to the same most popular relays in order to be more widely seen
|
||
|
|
- Many people are pulling from a large number of relays (including many duplicate events) in order to get more data
|
||
|
|
- Events are being copied between relays, oftentimes to many different relays
|
||
|
|
|
||
|
|
### Purposes
|
||
|
|
|
||
|
|
The purpose of this NIP is to help clients find the events of the people they follow, and to help nostr scale better.
|
||
|
|
|
||
|
|
### Suggestions
|
||
|
|
|
||
|
|
It is suggested that people spread their kind-10002 events to many relays, but to post their normal feed notes to a much smaller number of relays. It is suggested that clients offer a way for users to spread their Feed Advertisements to many more relays than they normally post to.
|
||
|
|
|
||
|
|
Authors may post events outside of the feed that they wish their followers to follow by posting them to relays outside of those listed in their "Feed Advertisement". For example, an author may want to reply to someone without all of their followers watching, but in many cases they want all their replies to show up in their "feed".
|
||
|
|
|
||
|
|
It is suggsted that relays allow any user to write their own kind-10002 event (optionally with AUTH to verify it is their own) even if they are not otherwise subscribed to the relay because
|
||
|
|
|
||
|
|
- finding where someone posts is rather important
|
||
|
|
- these events do not have content that needs management
|
||
|
|
- relays only need to store one replaceable event per pubkey to offer this service
|
||
|
|
|
||
|
|
### Example
|
||
|
|
|
||
|
|
```json
|
||
|
|
{
|
||
|
|
"kind": 10002,
|
||
|
|
"tags": [
|
||
|
|
["r", "wss://alicerelay.example.com"],
|
||
|
|
["r", "wss://brando-relay.com"],
|
||
|
|
["r", "wss://expensive-relay.example2.com"],
|
||
|
|
],
|
||
|
|
"content": "",
|
||
|
|
...other fields
|
||
|
|
```
|