mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 16:35:52 -05:00
81 lines
2.7 KiB
Markdown
81 lines
2.7 KiB
Markdown
NIP-0A
|
|
======
|
|
|
|
Follow List v2
|
|
--------------
|
|
|
|
An event with kind `103` means "follow list" which communicates the set of profiles
|
|
(represented by public keys) that the author is currently following.
|
|
|
|
The public keys followed are specified in "p" tags.
|
|
|
|
Additional "np" tags are present only to help with synchronization as described below.
|
|
|
|
The `.content` is not used.
|
|
|
|
## Tags
|
|
|
|
Each profile followed is reprsented in a "p" tag as follows:
|
|
|
|
```
|
|
["p", <pubkey>, <relay>, <petname>, <timestamp>]
|
|
```
|
|
|
|
Where
|
|
|
|
* `pubkey` is the hex encoded public key of the profile
|
|
* `relay` is an optional relay where the `pubkey` is known to post, or an empty string
|
|
* `petname` is an optional petname that the author uses for the contact, or an empty string
|
|
* `timestamp` is the time when the entry was added
|
|
|
|
## Removal of entries
|
|
|
|
Entries are not removed. Instead they are converted into "np" entries and their
|
|
timestamp is updated to time they are considered removed.
|
|
|
|
```
|
|
["np", <pubkey>, <relay>, <petname>, <timestamp2>]
|
|
```
|
|
|
|
Pubkeys MUST only be listed once in either a "p" tag or an "np" tag.
|
|
|
|
`p` means the person is counted as a contact. `np` means they are not counted as a contact
|
|
but the entry serves to help remember when they were removed so that conflicts can be
|
|
resolved.
|
|
|
|
Note that `np` is not searchable on relays.
|
|
|
|
All contacts should be listed. These events are complete lists, they are not change sets.
|
|
|
|
## Owner Handling
|
|
|
|
When you add a person, you find their entry and make sure the tag is "p" and not "np" and then you
|
|
update the timestamp to the current time. If missing, you create the entry.
|
|
|
|
When you remove a person, you find their entry and make sure the tag is "np" and not "p" and then
|
|
you update the timestamp to the current time. If missing, you create the entry.
|
|
|
|
When you receive your own contact list (presumably created by a different client), you merge it
|
|
with your local one and if the data has changed you publish the result. See
|
|
[Merge Operation](#merge-operation) below.
|
|
|
|
## Observers
|
|
|
|
A client that does not store any data can simply accept the latest contact list as probably
|
|
up to date.
|
|
|
|
Clients that do store data can instead choose to merge newer contact lists with the data they
|
|
already hold for the person's contacts that was created from previous events. The benefit of
|
|
doing this is only slight.
|
|
|
|
## Merge Operation
|
|
|
|
The merge operation is as follows: On a tag-by-tag basis, if only one event has a line for a pubkey,
|
|
you accept that line. If both events have a line for that pubkey, you take the line with the largest
|
|
timestamp.
|
|
|
|
## Rationale
|
|
|
|
This is functionally implements a Last-Write-Wins Element Set, which is a conflict-free replicated
|
|
data set with eventual consistency.
|