nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-30 11:55:51 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/master' into markdownlint

Browse Source 
# By Jon Staab (1) and others
# Via fiatjaf
* origin/master:
  nip01: remove misleading markdown example.
  Rephrase Markdown special rule
  Update old link to fiatjaf/nostr
  Clarify how NIP 45 works with multiple COUNT filters. (#504)

# Conflicts:
#	01.md
This commit is contained in:
Mariano Pérez Rodríguez 2023-05-08 11:11:36 -03:00
commit 1f89a2ad49
No known key found for this signature in database
GPG Key ID: 695E1DF7F390D47A
3 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
01.md
View File

@ -97,7 +97,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
## Basic Event Kinds ## Basic Event Kinds
- `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey. - `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey.
- `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say). Markdown links (`[]()` stuff) are not plaintext. - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say). Do not use Markdown! Clients should not have to guess how to interpret content like `[]()`. Use different event kinds for parsable content.
- `2`: `recommend_server`: the `content` is set to the URL (e.g., `wss://somerelay.com`) of a relay the event creator wants to recommend to its followers. - `2`: `recommend_server`: the `content` is set to the URL (e.g., `wss://somerelay.com`) of a relay the event creator wants to recommend to its followers.
A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about. A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about.

8
45.md
View File

@ -4,21 +4,21 @@
`draft` `optional` `author:staab` `draft` `optional` `author:staab`
Relays may support the `COUNT` verb, which provides a mechanism for obtaining event counts. Relays may support the verb `COUNT`, which provides a mechanism for obtaining event counts.
## Motivation ## Motivation
Some queries a client may want to execute against connected relays are prohibitively expensive, for example, in order to retrieve follower counts for a given pubkey, a client must query all kind-3 events referring to a given pubkey and count them. The result may be cached, either by a client or by a separate indexing server as an alternative, but both options erode the decentralization of the network by creating a second-layer protocol on top of Nostr. Some queries a client may want to execute against connected relays are prohibitively expensive, for example, in order to retrieve follower counts for a given pubkey, a client must query all kind-3 events referring to a given pubkey only to count them. The result may be cached, either by a client or by a separate indexing server as an alternative, but both options erode the decentralization of the network by creating a second-layer protocol on top of Nostr.
## Filters and return values ## Filters and return values
This NIP defines a verb called `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md). This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
```json ```json
["COUNT", <subscription_id>, <filters JSON>...] ["COUNT", <subscription_id>, <filters JSON>...]
``` ```
Counts are returned using a `COUNT` response in the form `{count: <integer>}`. Relays may use probabilistic counts to reduce compute requirements. Counts are returned using a `COUNT` response in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
```json ```json
["COUNT", <subscription_id>, {"count": <integer>}] ["COUNT", <subscription_id>, {"count": <integer>}]

2
README.md
View File

@ -1,7 +1,7 @@
# NIPs # NIPs
NIPs stand for **Nostr Implementation Possibilities**. NIPs stand for **Nostr Implementation Possibilities**.
They exist to document what may be implemented by [Nostr](https://github.com/fiatjaf/nostr)-compatible _relay_ and _client_ software. They exist to document what may be implemented by [Nostr](https://github.com/nostr-protocol/nostr)-compatible _relay_ and _client_ software.
--- ---