nips/0A.md

NIP-0A
======

Contact List v2
---------------

This is an early draft, I'm still working out the details.

## Events and Tags

Events have tags like this for each contact:

```
    ["p", <pubkey1>, <relay>, <petname>, <timestamp1>]
    ["np", <pubkey2>, <relay>, <petname>, <timestamp2>]
```

`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.

All contacts in the stated range 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 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.

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.

## 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
data set with eventual consistency.