mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-08-19 17:10:48 -04:00
01.md
02.md
03.md
04.md
05.md
06.md
07.md
08.md
09.md
10.md
11.md
12.md
13.md
14.md
15.md
16.md
17.md
18.md
19.md
20.md
21.md
22.md
23.md
24.md
25.md
26.md
27.md
28.md
29.md
30.md
31.md
32.md
33.md
34.md
35.md
36.md
37.md
38.md
39.md
40.md
42.md
44.md
45.md
46.md
47.md
48.md
49.md
50.md
51.md
52.md
53.md
54.md
55.md
56.md
57.md
58.md
59.md
60.md
61.md
62.md
64.md
65.md
66.md
68.md
69.md
70.md
71.md
72.md
73.md
75.md
78.md
7D.md
84.md
86.md
88.md
89.md
90.md
92.md
94.md
96.md
98.md
99.md
BREAKING.md
C0.md
C7.md
README.md
79 lines
2.8 KiB
Markdown
79 lines
2.8 KiB
Markdown
NIP-02
|
|
======
|
|
|
|
Follow List
|
|
-----------
|
|
|
|
`final` `optional`
|
|
|
|
A special event with kind `3`, meaning "follow list" is defined as having a list of `p` tags, one for each of the followed/known profiles one is following.
|
|
|
|
Each tag entry should contain the key for the profile, a relay URL where events from that key can be found (can be set to an empty string if not needed), and a local name (or "petname") for that profile (can also be set to an empty string or not provided), i.e., `["p", <32-bytes hex key>, <main relay URL>, <petname>]`.
|
|
|
|
The `.content` is not used.
|
|
|
|
For example:
|
|
|
|
```jsonc
|
|
{
|
|
"kind": 3,
|
|
"tags": [
|
|
["p", "91cf9..4e5ca", "wss://alicerelay.com/", "alice"],
|
|
["p", "14aeb..8dad4", "wss://bobrelay.com/nostr", "bob"],
|
|
["p", "612ae..e610f", "ws://carolrelay.com/ws", "carol"]
|
|
],
|
|
"content": "",
|
|
// other fields...
|
|
}
|
|
```
|
|
|
|
Every new following list that gets published overwrites the past ones, so it should contain all entries. Relays and clients SHOULD delete past following lists as soon as they receive a new one.
|
|
|
|
Whenever new follows are added to an existing list, clients SHOULD append them to the end of the list, so they are stored in chronological order.
|
|
|
|
## Uses
|
|
|
|
### Follow list backup
|
|
|
|
If one believes a relay will store their events for sufficient time, they can use this kind-3 event to backup their following list and recover on a different device.
|
|
|
|
### Profile discovery and context augmentation
|
|
|
|
A client may rely on the kind-3 event to display a list of followed people by profiles one is browsing; make lists of suggestions on who to follow based on the follow lists of other people one might be following or browsing; or show the data in other contexts.
|
|
|
|
### Relay sharing
|
|
|
|
A client may publish a follow list with good relays for each of their follows so other clients may use these to update their internal relay lists if needed, increasing censorship-resistance.
|
|
|
|
### Petname scheme
|
|
|
|
The data from these follow lists can be used by clients to construct local ["petname"](http://www.skyhunter.com/marcs/petnames/IntroPetNames.html) tables derived from other people's follow lists. This alleviates the need for global human-readable names. For example:
|
|
|
|
A user has an internal follow list that says
|
|
|
|
```json
|
|
[
|
|
["p", "21df6d143fb96c2ec9d63726bf9edc71", "", "erin"]
|
|
]
|
|
```
|
|
|
|
And receives two follow lists, one from `21df6d143fb96c2ec9d63726bf9edc71` that says
|
|
|
|
```json
|
|
[
|
|
["p", "a8bb3d884d5d90b413d9891fe4c4e46d", "", "david"]
|
|
]
|
|
```
|
|
|
|
and another from `a8bb3d884d5d90b413d9891fe4c4e46d` that says
|
|
|
|
```json
|
|
[
|
|
["p", "f57f54057d2a7af0efecc8b0b66f5708", "", "frank"]
|
|
]
|
|
```
|
|
|
|
When the user sees `21df6d143fb96c2ec9d63726bf9edc71` the client can show _erin_ instead;
|
|
When the user sees `a8bb3d884d5d90b413d9891fe4c4e46d` the client can show _david.erin_ instead;
|
|
When the user sees `f57f54057d2a7af0efecc8b0b66f5708` the client can show _frank.david.erin_ instead.
|