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

Merge pull request #921 from alexgleason/follows

Browse Source 
NIP-02: Rename Contact List to Follow List
This commit is contained in:
hodlbod 2023-12-07 10:03:55 -08:00 committed by GitHub
commit 730324f487
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
02.md
View File

@ -1,12 +1,12 @@
NIP-02 NIP-02
====== ======
Contact List and Petnames Follow List
------------------------- -----------
`final` `optional` `final` `optional`
A special event with kind `3`, meaning "contact list" is defined as having a list of `p` tags, one for each of the followed/known profiles one is following. 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.
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.
@ -25,27 +25,27 @@ For example:
} }
``` ```
Every new contact list that gets published overwrites the past ones, so it should contain all entries. Relays and clients SHOULD delete past contact lists as soon as they receive a new one. 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.
## Uses ## Uses
### Contact list backup ### 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. 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 ### 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 contact lists of other people one might be following or browsing; or show the data in other contexts. 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 ### Relay sharing
A client may publish a full list of contacts with good relays for each of their contacts so other clients may use these to update their internal relay lists if needed, increasing censorship-resistance. 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 ### Petname scheme
The data from these contact lists can be used by clients to construct local ["petname"](http://www.skyhunter.com/marcs/petnames/IntroPetNames.html) tables derived from other people's contact lists. This alleviates the need for global human-readable names. For example: 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 contact list that says A user has an internal follow list that says
```json ```json
[ [
@ -53,7 +53,7 @@ A user has an internal contact list that says
] ]
``` ```
And receives two contact lists, one from `21df6d143fb96c2ec9d63726bf9edc71` that says And receives two follow lists, one from `21df6d143fb96c2ec9d63726bf9edc71` that says
```json ```json
[ [

4
README.md
View File

@ -22,7 +22,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
## List ## List
- [NIP-01: Basic protocol flow description](01.md) - [NIP-01: Basic protocol flow description](01.md)
- [NIP-02: Contact List and Petnames](02.md) - [NIP-02: Follow List](02.md)
- [NIP-03: OpenTimestamps Attestations for Events](03.md) - [NIP-03: OpenTimestamps Attestations for Events](03.md)
- [NIP-04: Encrypted Direct Message](04.md) - [NIP-04: Encrypted Direct Message](04.md)
- [NIP-05: Mapping Nostr keys to DNS-based internet identifiers](05.md) - [NIP-05: Mapping Nostr keys to DNS-based internet identifiers](05.md)
@ -80,7 +80,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `0` | Metadata | [1](01.md) | | `0` | Metadata | [1](01.md) |
| `1` | Short Text Note | [1](01.md) | | `1` | Short Text Note | [1](01.md) |
| `2` | Recommend Relay | | | `2` | Recommend Relay | |
| `3` | Contacts | [2](02.md) | | `3` | Follows | [2](02.md) |
| `4` | Encrypted Direct Messages | [4](04.md) | | `4` | Encrypted Direct Messages | [4](04.md) |
| `5` | Event Deletion | [9](09.md) | | `5` | Event Deletion | [9](09.md) |
| `6` | Repost | [18](18.md) | | `6` | Repost | [18](18.md) |