text fixes.

Co-authored-by: Leo Wandersleb <leo@leowandersleb.de>

21.md

@@ -1,68 +0,0 @@
-NIP-21
-======
-
-Non-public encrypted messages
------------------------------
-
-`draft` `optional` `author:fiatjaf`
-
-This NIP defines a method for relays to verify the identity of the client that is requesting ["encrypted directed messages"](04.md) and only allow these clients to see messages authored by them or intended for them.
-
-When connecting to relays that support this NIP, clients SHOULD send an event of kind `20001`, meaning "client identification", with the content set to `"client identification for <relay hostname>"`.
-
-The relay MUST then use the event to verify the identity of the client and discard it afterwards. In the verification process the relay MUST check:
-
-  1. if event signature is valid;
-  2. if the content phrase matches the canonical phrase with the actual relay hostname in it;
-  3. if the event timestamp is not too far from the relay's current timestamp.
-
-If all is well, then the relay can use the identified pubkey to validate further requests for kind-4 events and only return kind-4 events that were either authored by the identified pubkey (`"pubkey": ...`) or are addressed to the identified pubkey (`"tags": ["p", ...]`).
-
-### Example
-
-1. Client connects to `wss://chat.relay.nostr.com/`
-2. Client sends `["EVENT", {"id": "...", "pubkey": "aeae...", "sig": "...", "kind": 20001, "tags": [], "created_at": 1609470000, "content": "client identification for chat.relay.nostr.com"}]`
-3. Client sends `["REQ", "my-dms", {"kinds": [4], "#p": ["aeae..."]}, {"kinds": [4],"authors": ["aeae"]}]`
-4. Relay sends `["EVENT", "my-dms", {"id": "...", "pubkey": "aeae...", "kind": 4, "content": "<encrypted>", "sig": "...", "tags": ["p", "786b..."]}]`
-5. Relay sends `["EVENT", "my-dms", {"id": "...", "pubkey": "786b...", "kind": 4, "content": "<encrypted>", "sig": "...", "tags": ["p", "aeae..."]}]`
-
-Ids and signatures omitted and pubkeys shortened for readability.
-
-## Rationale
-
-[NIP-04](04.md) is flawed because its event contents are encrypted, but the metadata around it is not, and by the nature of Nostr as a protocol designed for public communication in general anyone is able to query relays for any event they want -- thus it's possible to anyone to track conversations between any other Nostr users, not _exactly what_ they're saying, but to whom they're chatting and how often.
-
-Thus it's ironic that an end-to-end encrypted messaging protocol (such as NIP-04) turns out to be less private then a not end-to-end encrypted messaging protocol (such as Telegram).
-
-Telegram and other widely used direct messaging apps are generally trusted not only to not reveal metatada, but also to not reveal the contents of the messages, to which they have direct access.
-
-Other messaging services, deemed more private, such as Signal, do not have the contents of the conversations as these are end-to-end encrypted, but do have the metadata, and are trusted to not reveal that.
-
-This NIP, if used in conjunction with relays that are trusted to honor it and not leak private data, makes it so Nostr direct messaging is strictly superior to Telegram[^1] and on par with Signal[^2].
-
-[^1]: Not considering, of course, the million other features Telegram offers, that are irrelevant to this document.
-[^2]: Not considering, of course, the cryptographic protocols that Signal uses to provide forward secrecy and other advanced functionality which are already not present in NIP-04.
-
-## Comparison with other proposals
-
-Over the last months a number of other proposals were made to try to improve the lack of privacy NIP-04 provides[^3][^4][^5].
-
-Although all these proposals solve the issue in some way of another, and it can be argued they are superior to the current (although that can be disputed[^6][^7]), they generally have two shortcomings:
-
-  1. They add a lot of complexity: NIP-04 is very simple and direct, these other proposals are much more involved. More complexity means less clients and less decentralization.
-  2. They are incompatible with the broader Nostr identity scheme: one of the important strengths of Nostr is the ability of relays to identify the authors of events and decide if they are spammers or not, and if they want to store and relay these events or not these or not (for example, based on payment or some other form of registration). Ephemeral public keys or key aliases break these, or at least make them much harder to implement on the relay and client sides, which brings us back to point 1.
-
-[^3]: https://github.com/nostr-protocol/nostr/issues/69
-[^4]: https://github.com/nostr-protocol/nostr/pull/71/files
-[^5]: https://github.com/nostr-protocol/nips/pull/17
-[^6]: For example, even with ephemeral keys, if the general public still have access to all the events some time-analyses and other heuristics can be used to try to track chat activity between Nostr users.
-[^7]: Another example: even with ephemeral keys, it can be assumed that relays will know at least the IP address of the clients that are using it for the kind-4 messages, so they will have almost as much metadata as before -- which brings us back, again, to some level of trust on these relays to not reveal this metadata to the public, as in the current proposal.
-
-## Further possibilities
-
-Some random things that can be optionally done based on this NIP:
-
-  1. If relays can now get the public key of a client that is using it for direct messages, it can also give read reports to the ones who sent the messages (because it will know when the other side of the conversation have requested and received each message in the chat). This is a UX improvement that can't be achieved otherwise.
-  2. Clients can obfuscate the global view relays would have from their metadata by using multiple relays and only sending direct messages to one (or a few) at a time. Thus, if two peers share relays A and B, they can send 50% of the messages through relay A and 50% through relay B.
-
-These possibilities can be specified better on further NIPs.

23.md

@@ -0,0 +1,93 @@
+NIP-23
+======
+
+Relays List
+-----------
+
+`draft` `optional` `author:fiatjaf` `author:cameri` `author:monlovesmango` `author:giszmo`
+
+A special event with kind `10001`, meaning "relay list" is defined as having a list of tags, one for each relay the author uses.
+
+The content is not used.
+
+The tags consist of arrays of 3 elements: the first is the relay URL, the second is the _read_ condition, the third is the _write_ condition.
+
+The _read_ condition consists of a string containing a rule that follows a subset of the [runes](https://pypi.org/project/runes/) language. Specifically only the `|`, `&`, `!`, `>`, `<`, `/` and `=` operators are allowed. When the rule is an empty string it evaluates to `true`. All the operators must be tested against all possible values in the case of filter values that consist of lists of values and also in the case of event tags that can have multiple values for the same tag -- in other words, the `=` may be interpreted as a `values.any(v => v == runeValue)` instead of an `values == runeValue` operator; the `<` may be interpreted as a `values.any(v => v < runeValue)` and so on. Event tags are identified just by their tag key (for example, `e` or `p`) without the `#` prefix used in filters.
+
+The `read` rule operates on the values of the [NIP-01](01.md) **filter** object, while the `write` rule operates on the values of the **event** object.
+
+When a `read` rule evaluates to `false` for a given **filter** the client SHOULD NOT send that filter in a `REQ` message to that relay.
+
+When a `write` rule evaluates to `false` for a given **event** the client SHOULD NOT send that event in an `EVENT` message to that relay.
+
+When a rule is malformed or the client is unable to parse it for any reason (for example, for not having implemented all the operators) it SHOULD treat it as `true` if it is a _read_ rule and `false` if it is a _write_ rule.
+
+### Purposes
+
+This NIP serves two purposes: (1) backup and interoperability of relay lists and relay specific rules between clients; and (2) sharing of relay URLs between users.
+
+The first use case is meant to make it so users can open their client -- or different clients -- in different devices and have their list of relays automatically fetched from a default relay and start using their relays list without having to set everything up again.
+
+For the second purpose, if any client decides to, they can show to the user what relays other users are using, suggest that or automatically add these to the user's relay list, this can take into account the rules or more likely not. The possibility of sharing a list of relays in standardized format is good for spreading information about relays and contributes to the censorship-resistance of the network.
+
+### Use cases
+
+A client can expose to the user a set of premade rule templates (the user doesn't have to see the rules) for common relay policies, for example:
+
+  - "do not use this relay for DMs": sets _write_  to `kind/4`
+  - "only use this relay for DMs": sets _write_ to `kind=4` and _read_ to `kinds=4`
+  - "this is Bob's personal relay, only use it to fetch Bob's events": sets _write_ to `!` and _read_ to `authors=<bob-pubkey>`
+  - "this relay is full of spambots, do not get note replies from this relay": sets _read_ to `kinds=1&e!|kinds/1`
+  - "this is my personal relay, only store my stuff in it": sets _read_ to `authors=<my-pubkey>` _write_ to `pubkey=<my-pubkey>`
+
+### Examples
+
+(Public keys are shortened to 4 characters for readability.)
+
+- Rule evaluation examples:
+
+  - _read_
+
+    - for the filter `{"kinds": [0, 1, 2, 3], "authors": ["abcd", "1234"]}`
+
+      - `<empty>`: `true`
+      - `!`: `invalid` -> `true`
+      - `zjhcxb`: `invalid` -> `true`
+      - `false`: `invalid` -> `true`
+      - `true`: `invalid` -> `true`
+      - `authors=7890`: `false`
+      - `authors=7890|authors=1234`: `true`
+      - `authors=7890&authors=1234`: `false`
+      - `e!`: `true`
+      - `e=5555`: `false`
+      - `kinds=1|kinds=4`: `true`
+      - `kinds<2`: `true`
+      - `kinds>7`: `false`
+      - `kinds=1|kinds=7&authors=8543|authors=1234`: `true`
+
+  - _write_
+
+    - for the event `{"kind": 7, "content": "banana", "tags": ["p", "6677"], "created_at": 123456789, "pubkey": "e3e3"}`
+
+      - `<empty>`: `true`
+      - `!`: `invalid` -> `false`
+      - `7237237`: `invalid` -> `false`
+      - `****`: `invalid` -> `false`
+      - `pubkey=7890`: `false`
+      - `pubkey=e3e3`: `true`
+      - `kind=7&p=6677`: `true`
+      - `created_at>999999999|e=5a5a`: `false`
+
+- Full example of a kind 10001 event:
+
+```json
+{
+  "kind": 10001,
+  "tags": [
+    ["wss://alicerelay.com/", "", ""],
+    ["wss://bobrelay.com/", "authors=ef87", "!"],
+    ["wss://carolrelay.com/", "", ""],
+  ],
+  "content": "",
+  ...other fields
+```

README.md

@@ -18,20 +18,21 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 - [NIP-14: Subject tag in text events.](14.md)
 - [NIP-15: End of Stored Events Notice](15.md)
 - [NIP-16: Event Treatment](16.md)
+- [NIP-23: Relays List](23.md)
 - [NIP-25: Reactions](25.md)
 
 ## Event Kinds
 
-| kind  | description               | NIP  |
-|-------|---------------------------|------|
-| 0     | Metadata                  | 1, 5 |
-| 1     | Text                      | 1    |
-| 2     | Recommend Relay           | 1    |
-| 3     | Contacts                  | 2    |
-| 4     | Encrypted Direct Messages | 4    |
-| 5     | Event Deletion            | 9    |
-| 7     | Reaction                  | 25   |
-| 20001 | Client Identification     | 21   |
+| kind   | description                 | NIP    |
+| ------ | --------------------------- | ------ |
+| 0      | Metadata                    | 1, 5   |
+| 1      | Text                        | 1      |
+| 2      | Recommend Relay             | 1      |
+| 3      | Contacts                    | 2      |
+| 4      | Encrypted Direct Messages   | 4      |
+| 5      | Event Deletion              | 9      |
+| 7      | Reaction                    | 25     |
+| 10001  | Relays List                 | 23     |
 
 Please update this list when proposing NIPs introducing new event kinds.