Compare commits

...

4 Commits

Author SHA1 Message Date
Arman The Parman d795d758c7
Merge 850025478f into a551c5b693 2024-06-25 14:20:38 -03:00
Asai Toshiya a551c5b693 NIP-89: fix `REQ` examples 2024-06-25 12:17:39 -03:00
Arman The Parman 850025478f
Update 02.md
Fewer words, as suggested.
2024-06-19 13:04:27 +10:00
Arman The Parman a20add84da
follow list rewording
A suggesting to make readability better.
2024-06-18 15:44:07 +10:00
2 changed files with 7 additions and 8 deletions

11
02.md
View File

@ -6,12 +6,11 @@ Follow List
`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.
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` is not used.
A special event with kind `3`, meaning "follow list", is defined as having a list of `p` tags, one for each of the profiles to be followed.
Each "p" tag entry should have a pubkey string as the second element.
The third and fourth elements can be empty strings, or the relay URL and "petname", respectively.
The `.content` key is not used.
For example:
```json
@ -27,7 +26,7 @@ For example:
}
```
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.
Every new following list that gets published overwrites all previous 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.

4
89.md
View File

@ -116,7 +116,7 @@ User B might see in their timeline an event referring to a `kind:31337` event (e
User B's client, not knowing how to handle a `kind:31337` might display the event using its `alt` tag (as described in NIP-31). When the user clicks on the event, the application queries for a handler for this `kind`:
```json
["REQ", <id>, '[{ "kinds": [31989], "#d": ["31337"], 'authors': [<user>, <users-contact-list>] }]']
["REQ", <id>, { "kinds": [31989], "#d": ["31337"], "authors": [<user>, <users-contact-list>] }]
```
User B, who follows User A, sees that `kind:31989` event and fetches the `a`-tagged event for the app and handler information.
@ -127,5 +127,5 @@ User B's client sees the application's `kind:31990` which includes the informati
Alternatively, users might choose to query directly for `kind:31990` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms or querying high-quality restricted relays to avoid directing users to malicious handlers.
```json
["REQ", <id>, '[{ "kinds": [31990], "#k": [<desired-event-kind>], 'authors': [...] }]']
["REQ", <id>, { "kinds": [31990], "#k": [<desired-event-kind>], "authors": [...] }]
```