Mirror/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2025-01-31 02:21:33 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

more

Browse Source
This commit is contained in:
Mike Dilger 2025-01-03 09:20:22 +13:00
parent 4dc79e2687
commit a58e71bcab
No known key found for this signature in database
GPG Key ID: 47581A78D4329BA4
1 changed files with 13 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
0A.md
View File

@ -1,8 +1,8 @@
NIP-0A
======
Follow List v2
--------------
Synchronized Contact List
-------------------------
An addressable event with kind `33000` means "follow list" which communicates the set of profiles (represented by public keys) that the author is currently following.
@ -51,11 +51,11 @@ Note that `np` is not searchable on relays.
### Ownership (your own list)
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 add a person, you find their entry and if it is an "np", you change it to a "p" and update the timestamp to the current time. If missing, you create the "p" 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 remove a person, you find their entry and if it is a "p", you change it to a "np" and update the timestamp to the current time. If missing, you create the "np" entry.
When you receive your own follow list, you merge it with your local one and if the data has changed you publish the result. See [Merge Operation](#merge-operation) below. This resolves forks.
When you receive your own follow list, you merge it with any previous data you had. If the result changes the previous data you had, then you generate a new kind 33000 event and publish it. See [Merge Operation](#merge-operation) below. This resolves forks.
Clients MUST read the latest follow list from a relay and merge it before writing a newer follow list to minimize the chance of clobbering.
@ -69,13 +69,18 @@ The merge operation is as follows: On a tag-by-tag basis, if only one event has
### Relay to use
These events are published to the author's outbox relays. They do not need to be delivered to the inboxes of all the people tagged.
These events are published to the author's outbox relays. They shouldn't be delivered to the inboxes of all the people tagged.
### Interaction with kind=3 events
Clients supporting this NIP should consider these newer events to supercede any kind-3 events by the same author. For their own user's follow list, they should NOT try to merge in data from updated kind-3 events. However if there is no kind-33000 event available, they may migrate from the latest kind-3 event to the first kind-33000 event.
*This section is still being worked out*
Clients supporting this NIP should also publish kind-3 events that reflect the latest follow list whenever they publish kind-33000 events.
Ideas:
* Clients supporting this NIP should consider these newer events to supercede any kind-3 events by the same author.
* For their own user's follow list, if a kind-3 event is found that is newer than the newest kind-33000 event, clients can choose what to do about that (this is not an easy situation to resolve).
* If there is no kind-33000 event available, clients should migrate data from the latest kind-3 event to the first kind-33000 event.
* Clients supporting this NIP should also publish kind-3 events that reflect the latest follow list whenever they publish kind-33000 events.
## Uses