Mirror/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2025-02-07 13:59:04 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

more

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

12
0A.md
View File

@ -1,10 +1,10 @@
NIP-0A NIP-0A
====== ======
Synchronized Contact List Synchronized Follow 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. An addressable event with kind `33000` means "synchronized follow list" which communicates the set of profiles (represented by public keys) that the author is currently following.
The term "following" is left undefined, see ["Uses"](#uses). The term "following" is left undefined, see ["Uses"](#uses).
@ -12,7 +12,7 @@ The public keys followed are specified in "p" tags.
Additional "np" tags are present only to help with synchronization as described below. Additional "np" tags are present only to help with synchronization as described below.
A "d" tag is specified to indicate the client (or possibly client installation) that created the event. This helps prevent cross-client clobbers. A "d" tag is specified to indicate the client (or possibly client installation) that created the event.
The `.content` is not used. The `.content` is not used.
@ -135,6 +135,6 @@ When the user sees `f57f54057d2a7af0efecc8b0b66f5708` the client can show _frank
## Rationale ## Rationale
This functionally implements a Last-Write-Wins Element Set, which is a conflict-free replicated data set with eventual consistency. This functionally implements a Last-Write-Wins Element Set, which is a [conflict-free replicated data set](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) with eventual consistency.
We use replaceable events so that superceded events can be erased by relays. This brings back a per-relay clobbering issue, and so we use addressable events to limit such clobbering. We use replaceable events so that superceded events can be erased by relays. This brings back a per-relay clobbering issue, and so we use addressable events to prevent cross-client clobbering. We still need the CRDT functionality to resolve forks (usually occuring across different relays).