nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-24 17:35:50 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Add kinds 10 and 11 to prevent race conditions when updating contact lists

Browse Source
This commit is contained in:
Jonathan Staab 2023-03-10 11:22:59 -06:00 committed by Jon Staab
parent 735134a301
commit 13e0e5f9af
2 changed files with 5 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
02.md
View File

@ -6,7 +6,7 @@ Follow List
`final` `optional` `final` `optional`
A special event with kind `3`, meaning "follow list" is defined as having a list of `p` tags, one for each of the followed/known profiles one is following. Three special events having kinds `3`, `10`, and `11` are defined as having a list of `p` tags. Kind `3` defines the complete set of pubkeys one is following at a given point in time; kind `10` adds one or more pubkeys to that list; and kind `11` removes one or more pubkeys from that list.
Each tag entry should contain the key for the profile, a relay URL where events from that key can be found (can be set to an empty string if not needed), and a local name (or "petname") for that profile (can also be set to an empty string or not provided), i.e., `["p", <32-bytes hex key>, <main relay URL>, <petname>]`. The `content` can be anything and should be ignored. Each tag entry should contain the key for the profile, a relay URL where events from that key can be found (can be set to an empty string if not needed), and a local name (or "petname") for that profile (can also be set to an empty string or not provided), i.e., `["p", <32-bytes hex key>, <main relay URL>, <petname>]`. The `content` can be anything and should be ignored.
@ -29,6 +29,8 @@ Every new following list that gets published overwrites the past ones, so it sho
Whenever new follows are added to an existing list, clients SHOULD append them to the end of the list, so they are stored in chronological order. Whenever new follows are added to an existing list, clients SHOULD append them to the end of the list, so they are stored in chronological order.
When building a contact list, clients should query for the latest kind `3` event, and any subsequent kind `10` and `11` events that modify the original list. Contacts SHOULD use kind `10` and `11` in order to prevent race conditions when updating contact lists from multiple clients simultaneously, unless the intention is to write a canonical, complete contact list.
## Uses ## Uses
### Follow list backup ### Follow list backup

2
README.md
View File

@ -90,6 +90,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `6` | Repost | [18](18.md) | | `6` | Repost | [18](18.md) |
| `7` | Reaction | [25](25.md) | | `7` | Reaction | [25](25.md) |
| `8` | Badge Award | [58](58.md) | | `8` | Badge Award | [58](58.md) |
| `10` | Follow Contact | [2](02.md) |
| `11` | Unfollow Contact | [2](02.md) |
| `16` | Generic Repost | [18](18.md) | | `16` | Generic Repost | [18](18.md) |
| `40` | Channel Creation | [28](28.md) | | `40` | Channel Creation | [28](28.md) |
| `41` | Channel Metadata | [28](28.md) | | `41` | Channel Metadata | [28](28.md) |