Merge 194d1d70a2 into 4aa18e329a

* Clarify which kinds have lifetime of 'regular'

* Missed space

* Document kind 41 as replaceable

* Revert "Document kind 41 as replaceable"

This reverts commit eead2f5a74.

01.md

@@ -92,7 +92,7 @@ Kinds specify how clients should interpret the meaning of each event and the oth
 
 And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:
 
-- for kind `n` such that `1000 <= n < 10000`, events are **regular**, which means they're all expected to be stored by relays.
+- for kind `n` such that `1000 <= n < 10000 || 4 <= n < 45 || n == 1 || n == 2`, events are **regular**, which means they're all expected to be stored by relays.
 - for kind `n` such that `10000 <= n < 20000 || n == 0 || n == 3`, events are **replaceable**, which means that, for each combination of `pubkey` and `kind`, only the latest event MUST be stored by relays, older versions MAY be discarded.
 - for kind `n` such that `20000 <= n < 30000`, events are **ephemeral**, which means they are not expected to be stored by relays.
 - for kind `n` such that `30000 <= n < 40000`, events are **parameterized replaceable**, which means that, for each combination of `pubkey`, `kind` and the `d` tag's first value, only the latest event MUST be stored by relays, older versions MAY be discarded.

22.md

@@ -0,0 +1,111 @@
+NIP-22
+======
+
+Comment
+-------
+
+`draft` `optional`
+
+A comment is meant to be used to comment on
+or reply to anything except event kinds
+whose specifications have already defined other
+ways to comment on or reply to them.
+
+For example, it can be used to comment on a [NIP-23](23.md) `kind:30023` nostr blog post
+or on an off-nostr news article or to reply to another comment.
+
+## Structure
+
+A comment is an event of `kind:1111` with plaintext `.content`
+(no HTML, no Markdown nor other formatting).
+
+**It must have a `k` tag** pointing to the kind of the subject being commented on.
+Its value has a prefix: `"n:"` for nostr subjects and other prefixes (listed in a section ahead)
+for things that aren't nostr events.
+
+For example, when commenting on a `kind:30023`, the `k` tag is set to "n:30023".
+When replying to another `kind:1111`, the `k` tag is set to "n:1111".
+
+The `k` tag is useful to fetch top-level comments about events of specific types, for example,
+by filtering with `{ "#k": ["n:30023"], "kinds": [1111] }`.
+
+**An uppercase `K` tag must also be present.** The difference is that it is set to the original post (the one starting the thread) kind.
+This way a client can request all comments related to the kind it supports, not only the top-level comments.
+
+### Threads
+
+**There is always an `o` tag** pointing to the original post that started the thread.
+Its value can be an event id (with an `"e:"` prefix),
+an event address (`"a:"` prefix) or others shown at below section. The second value
+is the optional recommended relay url where the referenced event may be found.
+This tag is useful to load all messages of a thread at once.
+
+Note that if commenting on a replaceable event, one can choose to add both id and address references.
+
+After the first value, the `o` tag may have a variable number of `<key><space-separator><value>` fields
+at any order. When the tag references an event id, both a a [NIP-65](65.md) pubkey hint and a relay hint
+are recommended fields while for an event address, just the relay hint.
+
+Examples:
+
+- `["o", "e:<event-id>", "p <event-pubkey, optional>", "r <relay-url, optional>"]`
+- `["o", "a:<event-kind>:<event-pubkey>:<d-tag, optional>", "r <relay-url, optional>"]`
+
+Also, **there is always an `r` tag** pointing to the subject being directly commented on or replied to, using the
+same structure of the `o` tag.
+This tag is useful to lazily load a thread.
+
+### Other possible `o`/`r` tag values and their corresponding `K/k` tag values
+
+| `o`/`r` tag | corresponding `K/k` tag |
+| - | - |
+| "r:`<url>`" | "r:`<domain>`" |
+| "t:`<topic>`" | "#:t" |
+| "g:`<geohash>`" | "#:g" |
+
+#### Thread Relays
+
+If the original post being commented on is a nostr event and
+the client supports the [NIP-65](65.md) relay usage spec,
+`kind:1111` events should be sent atleast to the original post author's `read` relays.
+
+### Event Examples
+
+```js
+{
+  kind: 1111,
+  content: 'Agree with your comment.',
+  tags: [
+    // referencing the OP
+    ["o", "r:https://abc.com/articles/1/"],
+    // replying to a parent kind:1111 comment
+    ["r", "e:5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36", "p f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca", "r wss://example.relay"],
+    // the OP "kind"; for an url, the kind is its domain
+    ["K", "r:https://abc.com"]
+    // the parent kind
+    ["k", "n:1111"]
+  ]
+  // other fields
+}
+```
+
+```js
+{
+  kind: 1111,
+  content: 'Great blog post! Check this out nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9.',
+  tags: [
+    // top-level comments have the same o and r tags
+    ["o", "a:30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "r wss://example.relay"],
+    ["r", "a:30023:3c9849383bdea883b0bd16fece1ed36d37e37cdde3ce43b17ea4e9192ec11289:f9347ca7", "r wss://example.relay"],
+    // the OP kind
+    ["K", "n:30023"]
+    // the parent kind
+    ["k", "n:30023"],
+    // the nostr:npub1... mentioned on .content
+    ["p", "84dee6e676e5bb67b4ad4e042cf70cbd8681155db535942fcc6a0533858a7240"]
+  ]
+  // other fields
+}
+```
+
+Note that ideally there are no `p` tags unless the pubkey is being mentioned on the `.content`.

98.md

@@ -55,7 +55,8 @@ Using the `Authorization` HTTP header, the `kind 27235` event MUST be `base64` e
 
 Example HTTP Authorization header:
 ```
-Authorization: Nostr eyJpZCI6ImZlOTY0ZTc1ODkwMzM2MGYyOGQ4NDI0ZDA5MmRhODQ5NGVkMjA3Y2JhODIzMTEwYmUzYTU3ZGZlNGI1Nzg3MzQiLCJwdWJrZXkiOiI2M2ZlNjMxOGRjNTg1ODNjZmUxNjgxMGY4NmRkMDllMThiZmQ3NmFhYmMyNGEwMDgxY2UyODU2ZjMzMDUwNGVkIiwiY29udGVudCI6IiIsImtpbmQiOjI3MjM1LCJjcmVhdGVkX2F0IjoxNjgyMzI3ODUyLCJ0YWdzIjpbWyJ1cmwiLCJodHRwczovL2FwaS5zbm9ydC5zb2NpYWwvYXBpL3YxL241c3AvbGlzdCJdLFsibWV0aG9kIiwiR0VUIl1dLCJzaWciOiI1ZWQ5ZDhlYzk1OGJjODU0Zjk5N2JkYzI0YWMzMzdkMDA1YWYzNzIzMjQ3NDdlZmU0YTAwZTI0ZjRjMzA0MzdmZjRkZDgzMDg2ODRiZWQ0NjdkOWQ2YmUzZTVhNTE3YmI0M2IxNzMyY2M3ZDMzOTQ5YTNhYWY4NjcwNWMyMjE4NCJ9
+Authorization: Nostr 
+eyJpZCI6ImZlOTY0ZTc1ODkwMzM2MGYyOGQ4NDI0ZDA5MmRhODQ5NGVkMjA3Y2JhODIzMTEwYmUzYTU3ZGZlNGI1Nzg3MzQiLCJwdWJrZXkiOiI2M2ZlNjMxOGRjNTg1ODNjZmUxNjgxMGY4NmRkMDllMThiZmQ3NmFhYmMyNGEwMDgxY2UyODU2ZjMzMDUwNGVkIiwiY29udGVudCI6IiIsImtpbmQiOjI3MjM1LCJjcmVhdGVkX2F0IjoxNjgyMzI3ODUyLCJ0YWdzIjpbWyJ1IiwiaHR0cHM6Ly9hcGkuc25vcnQuc29jaWFsL2FwaS92MS9uNXNwL2xpc3QiXSxbIm1ldGhvZCIsIkdFVCJdXSwic2lnIjoiNWVkOWQ4ZWM5NThiYzg1NGY5OTdiZGMyNGFjMzM3ZDAwNWFmMzcyMzI0NzQ3ZWZlNGEwMGUyNGY0YzMwNDM3ZmY0ZGQ4MzA4Njg0YmVkNDY3ZDlkNmJlM2U1YTUxN2JiNDNiMTczMmNjN2QzMzk0OWEzYWFmODY3MDVjMjIxODQifQ
 ```
 
 ## Reference Implementations