Fleshed out further

0A.md

@@ -1,25 +1,51 @@
 NIP-0A
 ======
 
-Contact List v2
----------------
+Follow List v2
+--------------
 
-This is an early draft, I'm still working out the details.
+An event with kind `103` means "follow list" which communicates the set of profiles
+(represented by public keys) that the author is currently following.
 
-## Events and Tags
+The public keys followed are specified in "p" tags.
 
-Events have tags like this for each contact:
+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", <pubkey1>, <relay>, <petname>, <timestamp1>]
-    ["np", <pubkey2>, <relay>, <petname>, <timestamp2>]
+    ["p", <pubkey>, <relay>, <petname>, <timestamp>]
 ```
 
-`p` means the person is counted as a contact. `np` means they are not counted as a contact, but
-we are just remembering when they were removed.  Note that `np` is not searchable on relays.
+Where
 
-All contacts in the stated range should be listed. These events are complete lists, they are
-not change sets.
+* `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
 
@@ -30,11 +56,13 @@ When you remove a person, you find their entry and make sure the tag is "np" and
 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 publish the result. See [Merge Operation](#merge-operation) below.
+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.
+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
@@ -46,19 +74,6 @@ The merge operation is as follows: On a tag-by-tag basis, if only one event has
 you accept that line. If both events have a line for that pubkey, you take the line with the largest
 timestamp.
 
-## Possible Splitting (TBD)
-
-There are four kinds (to be assigned):
-
-  kind1 - all contacts whose public keys end with '0' - '3'
-  kind2 - all contacts whose public keys end with '4' - '7'
-  kind3 - all contacts whose public keys end with '8' - 'b'
-  kind4 - all contacts whose public keys end with 'c' - 'f'
-
-NOTE: We could actually continue to use kind3, as the 'timestamp' is additional and would
-be ignored by current software, as would the 'np' tags. However that wouldn't allow splitting the
-list into four chunks.
-
 ## Rationale
 
 This is functionally implements a Last-Write-Wins Element Set, which is a conflict-free replicated