5 files changed, 183 insertions, 40 deletions

diff --git a/01.md b/01.md
index e1e9444..68efc6f 100644
--- a/01.md
+++ b/01.md
@@ -26,7 +26,7 @@ The only object type that exists is the `event`, which has the following format
     ... // other kinds of tags may be included later
   ],
   "content": <arbitrary string>,
-  "sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
+  "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
 }
 ```
 
diff --git a/26.md b/26.md
index 0f8f64a..955a043 100644
--- a/26.md
+++ b/26.md
@@ -38,34 +38,20 @@ The following fields and operators are supported in the above query string:
 *Fields*:
 1. `kind`
    -  *Operators*:
-      -  `=${KIND_NUMBERS}` - delegatee may only sign events of listed kind(s) (comma-separated)
+      -  `=${KIND_NUMBER}` - delegatee may only sign events of this kind
 2. `created_at`
    -  *Operators*:
-      -  `<${TIMESTAMP}` - delegatee may only sign events whose `created_at` is ***before*** the specified timestamp
-      -  `>${TIMESTAMP}` - delegatee may only sign events whose `created_at` is ***after*** the specified timestamp
+      -  `<${TIMESTAMP}` - delegatee may only sign events created ***before*** the specified timestamp
+      -  `>${TIMESTAMP}` - delegatee may only sign events created ***after*** the specified timestamp
 
-Multiple conditions can be used in a single query string, including on the same field. Conditions must be combined with `&`.
-
-Multiple conditions should be treated as `AND` requirements; all conditions must be true for the delegated event to be valid.
-
-Multiple comma-separated `kind` values should be interpreted as:
-```
-# kind=0,1,3000
-... AND (kind == 0 OR kind == 1 OR kind == 3000) AND ...
-```
+In order to create a single condition, you must use a supported field and operator. Multiple conditions can be used in a single query string, including on the same field. Conditions must be combined with `&`.
 
 For example, the following condition strings are valid:
-- `kind=1`
-- `created_at<1675721813`
+
 - `kind=1&created_at<1675721813`
-- `kind=0,1,3000&created_at>1675721813`
+- `kind=0&kind=1&created_at>1675721813`
 - `kind=1&created_at>1674777689&created_at<1675721813`
 
-However, specifying multiple _separate_ `kind` conditions is impossible to satisfy:
-- `kind=1&kind=5`
-
-There is no way for an event to satisfy the `AND` requirement of being both `kind`s simultaneously.
-
 For the vast majority of use-cases, it is advisable that query strings should include a `created_at` ***after*** condition reflecting the current time, to prevent the delegatee from publishing historic notes on the delegator's behalf.
 
 #### Example
diff --git a/56.md b/56.md
new file mode 100644
index 0000000..55ee1a2
--- /dev/null
+++ b/56.md
@@ -0,0 +1,82 @@
+
+NIP-56
+======
+
+Reporting
+---------
+
+`draft` `optional` `author:jb55`
+
+A report is a `kind 1984` note that is used to report other notes for spam,
+illegal and explicit content.
+
+The content MAY contain additional information submitted by the entity
+reporting the content.
+
+Tags
+----
+
+The report event MUST include a `p` tag referencing the pubkey of the user you
+are reporting.
+
+If reporting a note, an `e` tag MUST also be included referencing the note id.
+
+A `report type` string MUST be included as the 3rd entry to the `e` or `p` tag
+being reported, which consists of the following report types:
+
+- `nudity` - depictions of nudity, porn, etc.
+- `profanity` - profanity, hateful speech, etc.
+- `illegal` - something which may be illegal in some jurisdiction
+- `spam` - spam
+- `impersonation` - someone pretending to be someone else
+
+Some report tags only make sense for profile reports, such as `impersonation`
+
+Example events
+--------------
+
+```json
+{
+  "kind": 1984,
+  "tags": [
+    [ "p", <pubkey>, "nudity"]
+  ],
+  "content": "",
+  ...
+}
+
+{
+  "kind": 1984,
+  "tags": [
+    [ "e", <eventId>, "illegal"],
+    [ "p", <pubkey>]
+  ],
+  "content": "He's insulting the king!",
+  ...
+}
+
+{
+  "kind": 1984,
+  "tags": [
+    [ "p", <impersonator pubkey>, "impersonation"],
+    [ "p", <victim pubkey>]
+  ],
+  "content": "Profile is imitating #[1]",
+  ...
+}
+```
+
+Client behavior
+---------------
+
+Clients can use reports from friends to make moderation decisions if they
+choose to. For instance, if 3+ of your friends report a profile as explicit,
+clients can have an option to automatically blur photos from said account.
+
+
+Relay behavior
+--------------
+
+It is not recommended that relays perform automatic moderation using reports,
+as they can be easily gamed. Admins could use reports from trusted moderators to
+takedown illegal or explicit content if the relay does not allow such things.
diff --git a/65.md b/65.md
new file mode 100644
index 0000000..c4fc246
--- /dev/null
+++ b/65.md
@@ -0,0 +1,70 @@
+NIP-65
+======
+
+Relay List Metadata
+-------------------
+
+`draft` `optional` `author:mikedilger`
+
+A special replaceable event meaning "Relay List Metadata" is defined as an event with kind `10002` having a list of `r` tags, one for each relay the author uses to either read or write to.
+
+The primary purpose of this relay list is to advertise to others, not for configuring one's client.
+
+The content is not used and SHOULD be blank.
+
+The `r` tags can have a second parameter as either `read` or `write`. If it is omitted, it means the author both reads from and writes to that relay.
+
+Clients SHOULD, as with all replaceable events, use only the most recent kind-10002 event they can find.
+
+### The meaning of read and write
+
+If an author advertises a write relay in a kind `10002` event, that means that feed-related events created by the author, which the author wants their followers to see, will be posted there. Normally these would be kind-1 Text Note events, but are not limited as such.
+
+Clients SHOULD presume that if their user has a pubkey in their ContactList (kind 3) that it is because they wish to see that author's feed-related events. But clients MAY presume otherwise.
+
+If an author advertises a read relay in a kind `10002` event, that means that the author may be subscribed to events that tag them on such relays. Clients SHOULD publish events that tag someone on at least some of the read relays of the person being tagged.
+
+### Motivation
+
+There is a common nostr use case where users wish to follow the content produced by other users. This is evidenced by the implicit meaning of the Contact List in [NIP-02](02.md)
+
+Because users don't often share the same sets of relays, ad-hoc solutions have arisen to get that content, but these solutions negatively impact scalability and decentralization:
+
+  - Most people are sending their posts to the same most popular relays in order to be more widely seen
+  - Many people are pulling from a large number of relays (including many duplicate events) in order to get more data
+  - Events are being copied between relays, oftentimes to many different relays
+
+### Purposes
+
+The purpose of this NIP is to help clients find the events of the people they follow, to help tagged events get to the people tagged, and to help nostr scale better.
+
+### Suggestions
+
+It is suggested that people spread their kind `10002` events to many relays, but write their normal feed-related events to a much smaller number of relays (between 2 to 6 relays). It is suggested that clients offer a way for users to spread their kind `10002` events to many more relays than they normally post to.
+
+Authors may post events outside of the feed that they wish their followers to follow by posting them to relays outside of those listed in their "Relay List Metadata".  For example, an author may want to reply to someone without all of their followers watching.
+
+It is suggested that relays allow any user to write their own kind `10002` event (optionally with AUTH to verify it is their own) even if they are not otherwise subscribed to the relay because
+
+  - finding where someone posts is rather important
+  - these events do not have content that needs management
+  - relays only need to store one replaceable event per pubkey to offer this service
+
+### Why not in kind `0` Metadata
+
+Even though this is user related metadata, it is a separate event from kind `0` in order to keep it small (as it should be widely spread) and to not have content that may require moderation by relay operators so that it is more acceptable to relays.
+
+### Example
+
+```json
+{
+  "kind": 10002,
+  "tags": [
+    ["r", "wss://alicerelay.example.com"],
+    ["r", "wss://brando-relay.com"],
+    ["r", "wss://expensive-relay.example2.com", "write"],
+    ["r", "wss://nostr-relay.example.com", "read"],
+  ],
+  "content": "",
+  ...other fields
+```
diff --git a/README.md b/README.md
index 829e61b..54bb5d4 100644
--- a/README.md
+++ b/README.md
@@ -30,28 +30,33 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 - [NIP-40: Expiration Timestamp](40.md)
 - [NIP-42: Authentication of clients to relays](42.md)
 - [NIP-50: Keywords filter](50.md)
+- [NIP-56: Reporting](56.md)
+- [NIP-65: Relay List Metadata](65.md)
 
 ## Event Kinds
 
-| kind        | description                 | NIP                    |
-|-------------|-----------------------------|------------------------|
-| 0           | Metadata                    | [1](01.md), [5](05.md) |
-| 1           | Text                        | [1](01.md)             |
-| 2           | Recommend Relay             | [1](01.md)             |
-| 3           | Contacts                    | [2](02.md)             |
-| 4           | Encrypted Direct Messages   | [4](04.md)             |
-| 5           | Event Deletion              | [9](09.md)             |
-| 7           | Reaction                    | [25](25.md)            |
-| 40          | Channel Creation            | [28](28.md)            |
-| 41          | Channel Metadata            | [28](28.md)            |
-| 42          | Channel Message             | [28](28.md)            |
-| 43          | Channel Hide Message        | [28](28.md)            |
-| 44          | Channel Mute User           | [28](28.md)            |
-| 45-49       | Public Chat Reserved        | [28](28.md)            |
-| 22242       | Client Authentication       | [42](42.md)            |
-| 10000-19999 | Replaceable Events Reserved | [16](16.md)            |
-| 20000-29999 | Ephemeral Events Reserved   | [16](16.md)            |
-| 30000-39999 | Param. Repl. Events Reserved| [33](33.md)            |
+| kind          | description                      | NIP                     |
+| ------------- | -------------------------------- | ----------------------- |
+| 0             | Metadata                         | [1](01.md), [5](05.md)  |
+| 1             | Short Text Note                  | [1](01.md)              |
+| 2             | Recommend Relay                  | [1](01.md)              |
+| 3             | Contacts                         | [2](02.md)              |
+| 4             | Encrypted Direct Messages        | [4](04.md)              |
+| 5             | Event Deletion                   | [9](09.md)              |
+| 7             | Reaction                         | [25](25.md)             |
+| 40            | Channel Creation                 | [28](28.md)             |
+| 41            | Channel Metadata                 | [28](28.md)             |
+| 42            | Channel Message                  | [28](28.md)             |
+| 43            | Channel Hide Message             | [28](28.md)             |
+| 44            | Channel Mute User                | [28](28.md)             |
+| 45-49         | Public Chat Reserved             | [28](28.md)             |
+| 1984          | Reporting                        | [56](56.md)             |
+| 10002         | Relay List Metadata              | [65](65.md)             |
+| 22242         | Client Authentication            | [42](42.md)             |
+| 1000-9999     | Regular Events                   | [16](16.md)             |
+| 10000-19999   | Replaceable Events               | [16](16.md)             |
+| 20000-29999   | Ephemeral Events                 | [16](16.md)             |
+| 30000-39999   | Parameterized Replaceable Events | [33](33.md)             |