NIP-02 ====== Follow List ----------- `final` `optional` 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>,
, ]`. The `content` can be anything and should be ignored. For example: ```json { "kind": 3, "tags": [ ["p", "91cf9..4e5ca", "wss://alicerelay.com/", "alice"], ["p", "14aeb..8dad4", "wss://bobrelay.com/nostr", "bob"], ["p", "612ae..e610f", "ws://carolrelay.com/ws", "carol"] ], "content": "", ...other fields } ``` Every new following list that gets published overwrites the past ones, so it should contain all entries. Relays and clients SHOULD delete past following lists as soon as they receive a new one. 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 ### Follow list backup If one believes a relay will store their events for sufficient time, they can use this kind-3 event to backup their following list and recover on a different device. ### Profile discovery and context augmentation A client may rely on the kind-3 event to display a list of followed people by profiles one is browsing; make lists of suggestions on who to follow based on the follow lists of other people one might be following or browsing; or show the data in other contexts. ### Relay sharing A client may publish a follow list with good relays for each of their follows so other clients may use these to update their internal relay lists if needed, increasing censorship-resistance. ### Petname scheme The data from these follow lists can be used by clients to construct local ["petname"](http://www.skyhunter.com/marcs/petnames/IntroPetNames.html) tables derived from other people's follow lists. This alleviates the need for global human-readable names. For example: A user has an internal follow list that says ```json [ ["p", "21df6d143fb96c2ec9d63726bf9edc71", "", "erin"] ] ``` And receives two follow lists, one from `21df6d143fb96c2ec9d63726bf9edc71` that says ```json [ ["p", "a8bb3d884d5d90b413d9891fe4c4e46d", "", "david"] ] ``` and another from `a8bb3d884d5d90b413d9891fe4c4e46d` that says ```json [ ["p", "f57f54057d2a7af0efecc8b0b66f5708", "", "frank"] ] ``` When the user sees `21df6d143fb96c2ec9d63726bf9edc71` the client can show _erin_ instead; When the user sees `a8bb3d884d5d90b413d9891fe4c4e46d` the client can show _david.erin_ instead; When the user sees `f57f54057d2a7af0efecc8b0b66f5708` the client can show _frank.david.erin_ instead.