nips/0A.md
2024-12-08 12:51:06 +13:00

2.7 KiB

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