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

# 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

01.md

@@ -97,7 +97,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
 ## 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.
-- `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.
 
 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.

45.md

@@ -4,21 +4,21 @@
 
 `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
 
-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
 
-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
 ["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
 ["COUNT", <subscription_id>, {"count": <integer>}]

README.md

@@ -1,7 +1,7 @@
 # NIPs
 
 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.
 
 ---