From a58e71bcab56ed4f4c86f8812d37c8074b58b6f6 Mon Sep 17 00:00:00 2001 From: Mike Dilger Date: Fri, 3 Jan 2025 09:20:22 +1300 Subject: [PATCH] more --- 0A.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/0A.md b/0A.md index 121fb882..b14422ac 100644 --- a/0A.md +++ b/0A.md @@ -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