upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorOscar Merry <MerryOscar@users.noreply.github.com>2024-08-05 23:08:41 +0100
committerGitHub <noreply@github.com>2024-08-05 23:08:41 +0100
commit29eec055c2ccf115dae3e8560506b480f1a6de05 (patch)
tree634fa65565d0bf40eca479de9851c0c95058af72
parent13b830d228b122b29f9d96a3bf10601406ddd646 (diff)
parent428a4779d7c4f4c2ff53815e8958e7cf99d69d26 (diff)
Merge branch 'nostr-protocol:master' into external-content-ids
-rw-r--r--01.md10
-rw-r--r--05.md4
-rw-r--r--07.md4
-rw-r--r--09.md8
-rw-r--r--15.md14
-rw-r--r--19.md3
-rw-r--r--21.md2
-rw-r--r--27.md2
-rw-r--r--28.md2
-rw-r--r--29.md1
-rw-r--r--32.md19
-rw-r--r--34.md32
-rw-r--r--39.md4
-rw-r--r--46.md8
-rw-r--r--47.md2
-rw-r--r--51.md1
-rw-r--r--65.md2
-rw-r--r--70.md45
-rw-r--r--72.md45
-rw-r--r--89.md4
-rw-r--r--96.md2
-rw-r--r--98.md3
-rw-r--r--99.md8
-rw-r--r--BREAKING.md4
-rw-r--r--README.md219
25 files changed, 274 insertions, 174 deletions
diff --git a/01.md b/01.md
index aa7fda2..1da6e83 100644
--- a/01.md
+++ b/01.md
@@ -87,12 +87,12 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key
87 87
88Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. This NIP defines two basic kinds: 88Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. This NIP defines two basic kinds:
89 89
90- `0`: **metadata**: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. [Extra metadata fields](24.md#kind-0) may be set. A relay may delete older events once it gets a new one for the same pubkey. 90- `0`: **user metadata**: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. [Extra metadata fields](24.md#kind-0) may be set. A relay may delete older events once it gets a new one for the same pubkey.
91- `1`: **text note**: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those. 91- `1`: **text note**: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those.
92 92
93And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation: 93And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:
94 94
95- for kind `n` such that `1000 <= n < 10000`, events are **regular**, which means they're all expected to be stored by relays. 95- 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.
96- 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. 96- 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.
97- for kind `n` such that `20000 <= n < 30000`, events are **ephemeral**, which means they are not expected to be stored by relays. 97- for kind `n` such that `20000 <= n < 30000`, events are **ephemeral**, which means they are not expected to be stored by relays.
98- 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. 98- 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.
@@ -125,8 +125,8 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
125 "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>, 125 "authors": <a list of lowercase pubkeys, the pubkey of an event must be one of these>,
126 "kinds": <a list of a kind numbers>, 126 "kinds": <a list of a kind numbers>,
127 "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of pubkeys, etc.>, 127 "#<single-letter (a-zA-Z)>": <a list of tag values, for #e — a list of event ids, for #p — a list of pubkeys, etc.>,
128 "since": <an integer unix timestamp in seconds, events must be newer than this to pass>, 128 "since": <an integer unix timestamp in seconds. Events must have a created_at >= to this to pass>,
129 "until": <an integer unix timestamp in seconds, events must be older than this to pass>, 129 "until": <an integer unix timestamp in seconds. Events must have a created_at <= to this to pass>,
130 "limit": <maximum number of events relays SHOULD return in the initial query> 130 "limit": <maximum number of events relays SHOULD return in the initial query>
131} 131}
132``` 132```
@@ -143,7 +143,7 @@ All conditions of a filter that are specified must match for an event for it to
143 143
144A `REQ` message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions. 144A `REQ` message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions.
145 145
146The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data. 146The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data.
147 147
148### From relay to client: sending events and notices 148### From relay to client: sending events and notices
149 149
diff --git a/05.md b/05.md
index 405078a..a1d488d 100644
--- a/05.md
+++ b/05.md
@@ -6,11 +6,11 @@ Mapping Nostr keys to DNS-based internet identifiers
6 6
7`final` `optional` 7`final` `optional`
8 8
9On events of kind `0` (`metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case-insensitive. 9On events of kind `0` (`user metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case-insensitive.
10 10
11Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`. 11Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`.
12 12
13The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier. 13The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `user's metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
14 14
15### Example 15### Example
16 16
diff --git a/07.md b/07.md
index 6c66322..9f836d8 100644
--- a/07.md
+++ b/07.md
@@ -24,6 +24,10 @@ async window.nostr.nip44.encrypt(pubkey, plaintext): string // returns ciphertex
24async window.nostr.nip44.decrypt(pubkey, ciphertext): string // takes ciphertext as specified in nip-44 24async window.nostr.nip44.decrypt(pubkey, ciphertext): string // takes ciphertext as specified in nip-44
25``` 25```
26 26
27### Recommendation to Extension Authors
28To make sure that the `window.nostr` is available to nostr clients on page load, the authors who create Chromium and Firefox extensions should load their scripts by specifying `"run_at": "document_end"` in the extension's manifest.
29
30
27### Implementation 31### Implementation
28 32
29See https://github.com/aljazceru/awesome-nostr#nip-07-browser-extensions. 33See https://github.com/aljazceru/awesome-nostr#nip-07-browser-extensions.
diff --git a/09.md b/09.md
index 5e79ac2..b6aa72c 100644
--- a/09.md
+++ b/09.md
@@ -6,9 +6,7 @@ Event Deletion
6 6
7`draft` `optional` 7`draft` `optional`
8 8
9A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` tags, each referencing an event the author is requesting to be deleted. 9A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a `k` tag for the kind of each event being deleted.
10
11Each tag entry must contain an "e" event id and/or `a` tags intended for deletion.
12 10
13The event's `content` field MAY contain a text note describing the reason for the deletion. 11The event's `content` field MAY contain a text note describing the reason for the deletion.
14 12
@@ -21,7 +19,9 @@ For example:
21 "tags": [ 19 "tags": [
22 ["e", "dcd59..464a2"], 20 ["e", "dcd59..464a2"],
23 ["e", "968c5..ad7a4"], 21 ["e", "968c5..ad7a4"],
24 ["a", "<kind>:<pubkey>:<d-identifier>"] 22 ["a", "<kind>:<pubkey>:<d-identifier>"],
23 ["k", "1"],
24 ["k", "30023"]
25 ], 25 ],
26 "content": "these posts were published by accident", 26 "content": "these posts were published by accident",
27 ...other fields 27 ...other fields
diff --git a/15.md b/15.md
index 55814fb..6daa801 100644
--- a/15.md
+++ b/15.md
@@ -6,7 +6,7 @@ Nostr Marketplace
6 6
7`draft` `optional` 7`draft` `optional`
8 8
9Based on https://github.com/lnbits/Diagon-Alley. 9Based on [Diagon-Alley](https://github.com/lnbits/Diagon-Alley).
10 10
11Implemented in [NostrMarket](https://github.com/lnbits/nostrmarket) and [Plebeian Market](https://github.com/PlebeianTech/plebeian-market). 11Implemented in [NostrMarket](https://github.com/lnbits/nostrmarket) and [Plebeian Market](https://github.com/PlebeianTech/plebeian-market).
12 12
@@ -139,7 +139,7 @@ Fields that are not self-explanatory:
139 139
140## Checkout events 140## Checkout events
141 141
142All checkout events are sent as JSON strings using ([NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md)). 142All checkout events are sent as JSON strings using [NIP-04](04.md).
143 143
144The `merchant` and the `customer` can exchange JSON messages that represent different actions. Each `JSON` message `MUST` have a `type` field indicating the what the JSON represents. Possible types: 144The `merchant` and the `customer` can exchange JSON messages that represent different actions. Each `JSON` message `MUST` have a `type` field indicating the what the JSON represents. Possible types:
145 145
@@ -150,7 +150,7 @@ The `merchant` and the `customer` can exchange JSON messages that represent diff
150| 2 | Merchant | Order Status Update | 150| 2 | Merchant | Order Status Update |
151 151
152### Step 1: `customer` order (event) 152### Step 1: `customer` order (event)
153The below JSON goes in content of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md). 153The below JSON goes in content of [NIP-04](04.md).
154 154
155```json 155```json
156{ 156{
@@ -182,7 +182,7 @@ _Open_: is `contact.nostr` required?
182 182
183Sent back from the merchant for payment. Any payment option is valid that the merchant can check. 183Sent back from the merchant for payment. Any payment option is valid that the merchant can check.
184 184
185The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md). 185The below JSON goes in `content` of [NIP-04](04.md).
186 186
187`payment_options`/`type` include: 187`payment_options`/`type` include:
188 188
@@ -217,7 +217,7 @@ The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/n
217 217
218Once payment has been received and processed. 218Once payment has been received and processed.
219 219
220The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md). 220The below JSON goes in `content` of [NIP-04](04.md).
221 221
222```json 222```json
223{ 223{
@@ -231,7 +231,7 @@ The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/n
231 231
232## Customize Marketplace 232## Customize Marketplace
233 233
234Create a customized user experience using the `naddr` from [NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md#shareable-identifiers-with-extra-metadata). The use of `naddr` enables easy sharing of marketplace events while incorporating a rich set of metadata. This metadata can include relays, merchant profiles, and more. Subsequently, it allows merchants to be grouped into a market, empowering the market creator to configure the marketplace's user interface and user experience, and share that marketplace. This customization can encompass elements such as market name, description, logo, banner, themes, and even color schemes, offering a tailored and unique marketplace experience. 234Create a customized user experience using the `naddr` from [NIP-19](19.md#shareable-identifiers-with-extra-metadata). The use of `naddr` enables easy sharing of marketplace events while incorporating a rich set of metadata. This metadata can include relays, merchant profiles, and more. Subsequently, it allows merchants to be grouped into a market, empowering the market creator to configure the marketplace's user interface and user experience, and share that marketplace. This customization can encompass elements such as market name, description, logo, banner, themes, and even color schemes, offering a tailored and unique marketplace experience.
235 235
236### Event `30019`: Create or update marketplace UI/UX 236### Event `30019`: Create or update marketplace UI/UX
237 237
@@ -331,7 +331,7 @@ Another thing that can happen is - if bids happen very close to the end date of
331 331
332## Customer support events 332## Customer support events
333 333
334Customer support is handled over whatever communication method was specified. If communicating via nostr, NIP-04 is used https://github.com/nostr-protocol/nips/blob/master/04.md. 334Customer support is handled over whatever communication method was specified. If communicating via nostr, [NIP-04](04.md) is used.
335 335
336## Additional 336## Additional
337 337
diff --git a/19.md b/19.md
index ef80887..cce9e64 100644
--- a/19.md
+++ b/19.md
@@ -34,8 +34,8 @@ These are the possible bech32 prefixes with `TLV`:
34 34
35 - `nprofile`: a nostr profile 35 - `nprofile`: a nostr profile
36 - `nevent`: a nostr event 36 - `nevent`: a nostr event
37 - `nrelay`: a nostr relay
38 - `naddr`: a nostr _replaceable event_ coordinate 37 - `naddr`: a nostr _replaceable event_ coordinate
38 - `nrelay`: a nostr relay (deprecated)
39 39
40These possible standardized `TLV` types are indicated here: 40These possible standardized `TLV` types are indicated here:
41 41
@@ -43,7 +43,6 @@ These possible standardized `TLV` types are indicated here:
43 - depends on the bech32 prefix: 43 - depends on the bech32 prefix:
44 - for `nprofile` it will be the 32 bytes of the profile public key 44 - for `nprofile` it will be the 32 bytes of the profile public key
45 - for `nevent` it will be the 32 bytes of the event id 45 - for `nevent` it will be the 32 bytes of the event id
46 - for `nrelay`, this is the relay URL
47 - for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced. For non-parameterized replaceable events, use an empty string. 46 - for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced. For non-parameterized replaceable events, use an empty string.
48- `1`: `relay` 47- `1`: `relay`
49 - for `nprofile`, `nevent` and `naddr`, _optionally_, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii 48 - for `nprofile`, `nevent` and `naddr`, _optionally_, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii
diff --git a/21.md b/21.md
index 6ed141a..988485d 100644
--- a/21.md
+++ b/21.md
@@ -10,7 +10,7 @@ This NIP standardizes the usage of a common URI scheme for maximum interoperabil
10 10
11The scheme is `nostr:`. 11The scheme is `nostr:`.
12 12
13The identifiers that come after are expected to be the same as those defined in [NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md) (except `nsec`). 13The identifiers that come after are expected to be the same as those defined in [NIP-19](19.md) (except `nsec`).
14 14
15## Examples 15## Examples
16 16
diff --git a/27.md b/27.md
index efd2c12..133f8ef 100644
--- a/27.md
+++ b/27.md
@@ -20,7 +20,7 @@ A reader client that receives an event with such `nostr:...` mentions in its `.c
20 20
21Suppose Bob is writing a note in a client that has search-and-autocomplete functionality for users that is triggered when they write the character `@`. 21Suppose Bob is writing a note in a client that has search-and-autocomplete functionality for users that is triggered when they write the character `@`.
22 22
23As Bob types `"hello @mat"` the client will prompt him to autocomplete with [mattn's profile](https://gateway.nostr.com/p/2c7cc62a697ea3a7826521f3fd34f0cb273693cbe5e9310f35449f43622a5cdc), showing a picture and name. 23As Bob types `"hello @mat"` the client will prompt him to autocomplete with [mattn's profile](https://njump.me/npub1937vv2nf06360qn9y8el6d8sevnndy7tuh5nzre4gj05xc32tnwqauhaj6), showing a picture and name.
24 24
25Bob presses "enter" and now he sees his typed note as `"hello @mattn"`, `@mattn` is highlighted, indicating that it is a mention. Internally, however, the event looks like this: 25Bob presses "enter" and now he sees his typed note as `"hello @mattn"`, `@mattn` is highlighted, indicating that it is a mention. Internally, however, the event looks like this:
26 26
diff --git a/28.md b/28.md
index 65ebb3f..1632088 100644
--- a/28.md
+++ b/28.md
@@ -37,7 +37,7 @@ In the channel creation `content` field, Client SHOULD include basic channel met
37 37
38Update a channel's public metadata. 38Update a channel's public metadata.
39 39
40Clients and relays SHOULD handle kind 41 events similar to kind 33 replaceable events, where the information is used to update the metadata, without modifying the event id for the channel.Only the most recent kind 41 is needed to be stored. 40Kind 41 is used to update the metadata without modifying the event id for the channel. Only the most recent kind 41 per `e` tag value MAY be available.
41 41
42Clients SHOULD ignore kind 41s from pubkeys other than the kind 40 pubkey. 42Clients SHOULD ignore kind 41s from pubkeys other than the kind 40 pubkey.
43 43
diff --git a/29.md b/29.md
index 0f4a579..74dfd66 100644
--- a/29.md
+++ b/29.md
@@ -119,6 +119,7 @@ Each moderation action uses a different kind and requires different arguments, w
119| 9004 | `remove-permission` | `p` (pubkey), `permission` (name) | 119| 9004 | `remove-permission` | `p` (pubkey), `permission` (name) |
120| 9005 | `delete-event` | `e` (id hex) | 120| 9005 | `delete-event` | `e` (id hex) |
121| 9006 | `edit-group-status` | `public` or `private`, `open` or `closed` | 121| 9006 | `edit-group-status` | `public` or `private`, `open` or `closed` |
122| 9007 | `create-group` | |
122 123
123- *group metadata* (`kind:39000`) (optional) 124- *group metadata* (`kind:39000`) (optional)
124 125
diff --git a/32.md b/32.md
index 79f5937..0fb765a 100644
--- a/32.md
+++ b/32.md
@@ -6,10 +6,9 @@ Labeling
6 6
7`draft` `optional` 7`draft` `optional`
8 8
9A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases, 9This NIP defines two new indexable tags to label events and a new event kind (`kind:1985`) to attach those labels to existing events. This supports several use cases, including distributed moderation, collection management, license assignment, and content classification.
10including distributed moderation, collection management, license assignment, and content classification.
11 10
12This NIP introduces two new tags: 11New Tags:
13 12
14- `L` denotes a label namespace 13- `L` denotes a label namespace
15- `l` denotes a label 14- `l` denotes a label
@@ -129,6 +128,20 @@ is labeling their note as being related to Milan, Italy using ISO 3166-2.
129} 128}
130``` 129```
131 130
131Author is labeling their note language as English using ISO-639-1.
132
133```json
134{
135 "kind": 1,
136 "tags": [
137 ["L", "ISO-639-1"],
138 ["l", "en", "ISO-639-1"]
139 ],
140 "content": "English text",
141 ...
142}
143```
144
132Other Notes 145Other Notes
133----------- 146-----------
134 147
diff --git a/34.md b/34.md
index fcc2cec..4989803 100644
--- a/34.md
+++ b/34.md
@@ -35,6 +35,36 @@ The `r` tag annotated with the `"euc"` marker should be the commit ID of the ear
35 35
36Except `d`, all tags are optional. 36Except `d`, all tags are optional.
37 37
38## Repository state announcements
39
40An optional source of truth for the state of branches and tags in a repository.
41
42```jsonc
43{
44 "kind": 30618,
45 "content": "",
46 "tags": [
47 ["d", "<repo-id>"], // matches the identifier in the coresponding repository announcement
48 ["refs/<heads|tags>/<branch-or-tag-name>","<commit-id>"]
49 ["HEAD", "ref: refs/heads/<branch-name>"]
50 ]
51}
52```
53
54The `refs` tag may appear multiple times, or none.
55
56If no `refs` tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike [NIP-09](09.md) deletion.
57
58The `refs` tag can be optionally extended to enable clients to identify how many commits ahead a ref is:
59
60```jsonc
61{
62 "tags": [
63 ["refs/<heads|tags>/<branch-or-tag-name>", "<commit-id>", "<shorthand-parent-commit-id>", "<shorthand-grandparent>", ...],
64 ]
65}
66```
67
38## Patches 68## Patches
39 69
40Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch events SHOULD include an `a` tag pointing to that repository's announcement address. 70Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch events SHOULD include an `a` tag pointing to that repository's announcement address.
@@ -53,7 +83,7 @@ The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply`
53 ["p", "<repository-owner>"], 83 ["p", "<repository-owner>"],
54 ["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention 84 ["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention
55 85
56 ["t", "root"], // ommited for additional patches in a series 86 ["t", "root"], // omitted for additional patches in a series
57 // for the first patch in a revision 87 // for the first patch in a revision
58 ["t", "root-revision"], 88 ["t", "root-revision"],
59 89
diff --git a/39.md b/39.md
index c819e43..b7c3b9c 100644
--- a/39.md
+++ b/39.md
@@ -12,9 +12,11 @@ Nostr protocol users may have other online identities such as usernames, profile
12 12
13## `i` tag on a metadata event 13## `i` tag on a metadata event
14 14
15A new optional `i` tag is introduced for `kind 0` metadata event contents in addition to name, about, picture fields as included in [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md): 15A new optional `i` tag is introduced for `kind 0` metadata event defined in [NIP-01](01.md):
16```json 16```json
17{ 17{
18 "id": <id>,
19 "pubkey": <pubkey>,
18 "tags": [ 20 "tags": [
19 ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"], 21 ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
20 ["i", "twitter:semisol_public", "1619358434134196225"], 22 ["i", "twitter:semisol_public", "1619358434134196225"],
diff --git a/46.md b/46.md
index 1528116..57fd2b0 100644
--- a/46.md
+++ b/46.md
@@ -28,7 +28,7 @@ The remote signer would provide a connection token in the form:
28bunker://<remote-user-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value> 28bunker://<remote-user-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
29``` 29```
30 30
31This token is pasted into the client by the user and the client then uses the details to connect to the remote signer via the specified relay(s). 31This token is pasted into the client by the user and the client then uses the details to connect to the remote signer via the specified relay(s). Optional secret can be used for single successfully established connection only, remote signer SHOULD ignore new attempts to establish connection with old optional secret.
32 32
33### Direct connection initiated by the client 33### Direct connection initiated by the client
34 34
@@ -101,7 +101,7 @@ nostrconnect://<local-keypair-pubkey>?relay=<wss://relay-to-connect-on>&metadata
101} 101}
102``` 102```
103 103
104The `content` field is a JSON-RPC-like message that is [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md) encrypted and has the following structure: 104The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted and has the following structure:
105 105
106```json 106```json
107{ 107{
@@ -148,7 +148,7 @@ The `connect` method may be provided with `optional_requested_permissions` for u
148} 148}
149``` 149```
150 150
151The `content` field is a JSON-RPC-like message that is [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md) encrypted and has the following structure: 151The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted and has the following structure:
152 152
153```json 153```json
154{ 154{
@@ -224,4 +224,4 @@ Coming soon...
224 224
225## References 225## References
226 226
227- [NIP-04 - Encryption](https://github.com/nostr-protocol/nips/blob/master/04.md) 227- [NIP-04 - Encryption](04.md)
diff --git a/47.md b/47.md
index 983d2c9..e4e432c 100644
--- a/47.md
+++ b/47.md
@@ -38,7 +38,7 @@ a plaintext string with the supported commands, space-separated, eg. `pay_invoic
38Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to. 38Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to.
39Optionally, a request can have an `expiration` tag that has a unix timestamp in seconds. If the request is received after this timestamp, it should be ignored. 39Optionally, a request can have an `expiration` tag that has a unix timestamp in seconds. If the request is received after this timestamp, it should be ignored.
40 40
41The content of requests and responses is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure: 41The content of requests and responses is encrypted with [NIP04](04.md), and is a JSON-RPCish object with a semi-fixed structure:
42 42
43Request: 43Request:
44```jsonc 44```jsonc
diff --git a/51.md b/51.md
index fb40b26..65bc484 100644
--- a/51.md
+++ b/51.md
@@ -32,6 +32,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
32| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group ids + mandatory relay URL) | 32| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group ids + mandatory relay URL) |
33| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) | 33| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) |
34| Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) | 34| Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) |
35| DM relays | 10050 | Where to receive [NIP-17](17.md) direct messages | `"relay"` (see [NIP-17](17.md)) |
35| Good wiki authors | 10101 | [NIP-54](54.md) user recommended wiki authors | `"p"` (pubkeys) | 36| Good wiki authors | 10101 | [NIP-54](54.md) user recommended wiki authors | `"p"` (pubkeys) |
36| Good wiki relays | 10102 | [NIP-54](54.md) relays deemed to only host useful articles | `"relay"` (relay URLs) | 37| Good wiki relays | 10102 | [NIP-54](54.md) relays deemed to only host useful articles | `"relay"` (relay URLs) |
37 38
diff --git a/65.md b/65.md
index 1a2d7e8..f32c965 100644
--- a/65.md
+++ b/65.md
@@ -37,7 +37,7 @@ When seeking events **about** a user, where the user was tagged, Clients SHOULD
37When broadcasting an event, Clients SHOULD: 37When broadcasting an event, Clients SHOULD:
38 38
39- Broadcast the event to the WRITE relays of the author 39- Broadcast the event to the WRITE relays of the author
40- Broadcast the event all READ relays of each tagged user 40- Broadcast the event to all READ relays of each tagged user
41 41
42## Motivation 42## Motivation
43 43
diff --git a/70.md b/70.md
new file mode 100644
index 0000000..043d5fb
--- /dev/null
+++ b/70.md
@@ -0,0 +1,45 @@
1NIP-70
2======
3
4Protected Events
5----------------
6
7`draft` `optional`
8
9When the `"-"` tag is present, that means the event is "protected".
10
11A protected event is an event that can only be published to relays by its author. This is achieved by relays ensuring that the author is [authenticated](42.md) before publishing their own events or by just rejecting events with `["-"]` outright.
12
13The default behavior of a relay MUST be to reject any event that contains `["-"]`.
14
15Relays that want to accept such events MUST first require that the client perform the [NIP-42](42.md) `AUTH` flow and then check if the authenticated client has the same pubkey as the event being published and only accept the event in that case.
16
17## The tag
18
19The tag is a simple tag with a single item: `["-"]`. It may be added to any event.
20
21## Example flow
22
23- User `79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798` connects to relay `wss://example.com`:
24
25```jsonc
26/* client: */
27["EVENT",{"id":"cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2","pubkey":"79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798","created_at":1707409439,"kind":1,"tags":[["-"]],"content":"hello members of the secret group","sig":"fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"}]
28/* relay: */
29["AUTH", "<challenge>"]
30["OK", "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2", false, "auth-required: this event may only be published by its author"]
31/* client: */
32["AUTH", {}]
33["EVENT",{"id":"cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2","pubkey":"79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798","created_at":1707409439,"kind":1,"tags":[["-"]],"content":"hello members of the secret group","sig":"fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"}]
34["OK", "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2", true, ""]
35```
36
37## Why
38
39There are multiple circumstances in which it would be beneficial to prevent the unlimited spreading of an event through all relays imaginable and restrict some to only a certain demographic or to a semi-closed community relay. Even when the information is public it may make sense to keep it compartimentalized across different relays.
40
41It's also possible to create closed access feeds with this when the publisher has some relationship with the relay and trusts the relay to not release their published events to anyone.
42
43Even though it's ultimately impossible to restrict the spread of information on the internet (for example, one of the members of the closed group may want to take an event intended to be restricted and republish it to other relays), most relays would be happy to not facilitate the acts of these so-called "pirates", in respect to the original decision of the author and therefore gladly reject these republish acts if given the means to.
44
45This NIP gives these authors and relays the means to clearly signal when a given event is not intended to be republished by third parties.
diff --git a/72.md b/72.md
index 5a8be0a..d19b80b 100644
--- a/72.md
+++ b/72.md
@@ -6,11 +6,11 @@ Moderated Communities (Reddit Style)
6 6
7`draft` `optional` 7`draft` `optional`
8 8
9The goal of this NIP is to create moderator-approved public communities around a topic. It defines the replaceable event `kind:34550` to define the community and the current list of moderators/administrators. Users that want to post into the community, simply tag any Nostr event with the community's `a` tag. Moderators issue an approval event `kind:4550` that links the community with the new post. 9The goal of this NIP is to enable public communities. It defines the replaceable event `kind:34550` to define the community and the current list of moderators/administrators. Users that want to post into the community, simply tag any Nostr event with the community's `a` tag. Moderators may issue an approval event `kind:4550`.
10 10
11# Community Definition 11# Community Definition
12 12
13`kind:34550` SHOULD include any field that helps define the community and the set of moderators. `relay` tags MAY be used to describe the preferred relay to download requests and approvals. 13`Kind:34550` SHOULD include any field that helps define the community and the set of moderators. `relay` tags MAY be used to describe the preferred relay to download requests and approvals. A community definition event's `d` tag MAY double as its name, but if a `name` tag is provided, it SHOULD be displayed instead of the `d` tag.
14 14
15```jsonc 15```jsonc
16{ 16{
@@ -18,6 +18,7 @@ The goal of this NIP is to create moderator-approved public communities around a
18 "kind": 34550, 18 "kind": 34550,
19 "tags": [ 19 "tags": [
20 ["d", "<community-d-identifier>"], 20 ["d", "<community-d-identifier>"],
21 ["name", "<Community name>"],
21 ["description", "<Community description>"], 22 ["description", "<Community description>"],
22 ["image", "<Community image url>", "<Width>x<Height>"], 23 ["image", "<Community image url>", "<Width>x<Height>"],
23 24
@@ -38,9 +39,9 @@ The goal of this NIP is to create moderator-approved public communities around a
38} 39}
39``` 40```
40 41
41# New Post Request 42# Posting to a community
42 43
43Any Nostr event can be submitted to a community by anyone for approval. Clients MUST add the community's `a` tag to the new post event in order to be presented for the moderator's approval. 44Any Nostr event can be posted to a community. Clients MUST add one or more community `a` tags, each with a recommended relay.
44 45
45```jsonc 46```jsonc
46{ 47{
@@ -53,11 +54,15 @@ Any Nostr event can be submitted to a community by anyone for approval. Clients
53} 54}
54``` 55```
55 56
56Community management clients MAY filter all mentions to a given `kind:34550` event and request moderators to approve each submission. Moderators MAY delete his/her approval of a post at any time using event deletions (See [NIP-09](09.md)). 57# Moderation
57 58
58# Post Approval by moderators 59Anyone may issue an approval event to express their opinion that a post is appropriate for a community. Clients MAY choose which approval events to honor, but SHOULD at least use ones published by the group's defined moderators.
59 60
60The post-approval event MUST include `a` tags of the communities the moderator is posting into (one or more), the `e` tag of the post and `p` tag of the author of the post (for approval notifications). The event SHOULD also include the stringified `post request` event inside the `.content` ([NIP-18-style](18.md)) and a `k` tag with the original post's event kind to allow filtering of approved posts by kind. 61An approval event MUST include one or more community `a` tags, an `e` or `a` tag pointing to the post, and the `p` tag of the author of the post (for approval notifications). `a` tag prefixes can be used to disambiguate between community and replaceable event pointers (community `a` tags always begin with `34550`).
62
63The event SHOULD also include the JSON-stringified `post request` event inside the `.content`, and a `k` tag with the original post's event kind to allow filtering of approved posts by kind.
64
65Moderators MAY delete their approval of a post at any time using NIP 09 event deletions.
61 66
62```jsonc 67```jsonc
63{ 68{
@@ -76,26 +81,16 @@ The post-approval event MUST include `a` tags of the communities the moderator i
76 81
77It's recommended that multiple moderators approve posts to avoid deleting them from the community when a moderator is removed from the owner's list. In case the full list of moderators must be rotated, the new moderator set must sign new approvals for posts in the past or the community will restart. The owner can also periodically copy and re-sign of each moderator's approval events to make sure posts don't disappear with moderators. 82It's recommended that multiple moderators approve posts to avoid deleting them from the community when a moderator is removed from the owner's list. In case the full list of moderators must be rotated, the new moderator set must sign new approvals for posts in the past or the community will restart. The owner can also periodically copy and re-sign of each moderator's approval events to make sure posts don't disappear with moderators.
78 83
79Post Approvals of replaceable events can be created in three ways: (i) by tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the replaceable event; (ii) by tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and (iii) by tagging the replaceable event with both its `e` and `a` tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI. Since relays are instructed to delete old versions of a replaceable event, the `.content` of an `e`-approval MUST have the specific version of the event or Clients might not be able to find that version of the content anywhere. 84Approvals of replaceable events can be created in three ways:
80 85
81Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be included in all `34550:*` `a` tags. 861. By tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the replaceable event
872. By tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and
883. By tagging the replaceable event with both its `e` and `a` tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI.
82 89
83# Displaying 90Since relays are instructed to delete old versions of a replaceable event, the `content` of an approval using an `e` tag MUST have the specific version of the event or clients might not be able to find that version of the content anywhere.
84 91
85Community clients SHOULD display posts that have been approved by at least 1 moderator or by the community owner. 92Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be approved for all `34550:*` `a` tags.
86 93
87The following filter displays the approved posts. 94# Cross-posting
88
89```json
90[
91 "REQ",
92 "_",
93 {
94 "authors": ["<owner-pubkey>", "<moderator1-pubkey>", "<moderator2-pubkey>", "<moderator3-pubkey>", ...],
95 "kinds": [4550],
96 "#a": ["34550:<Community event author pubkey>:<d-identifier of the community>"],
97 }
98]
99```
100 95
101Clients MAY hide approvals by blocked moderators at the user's request. 96Clients MAY support cross-posting between communities by posting a NIP 18 `kind 6` or `kind 16` repost to one or more communities using `a` tags as described above. The `content` of the repost MUST be the original event, not the approval event.
diff --git a/89.md b/89.md
index 43d197f..54aa30b 100644
--- a/89.md
+++ b/89.md
@@ -116,7 +116,7 @@ User B might see in their timeline an event referring to a `kind:31337` event (e
116User B's client, not knowing how to handle a `kind:31337` might display the event using its `alt` tag (as described in NIP-31). When the user clicks on the event, the application queries for a handler for this `kind`: 116User B's client, not knowing how to handle a `kind:31337` might display the event using its `alt` tag (as described in NIP-31). When the user clicks on the event, the application queries for a handler for this `kind`:
117 117
118```json 118```json
119["REQ", <id>, '[{ "kinds": [31989], "#d": ["31337"], 'authors': [<user>, <users-contact-list>] }]'] 119["REQ", <id>, { "kinds": [31989], "#d": ["31337"], "authors": [<user>, <users-contact-list>] }]
120``` 120```
121 121
122User B, who follows User A, sees that `kind:31989` event and fetches the `a`-tagged event for the app and handler information. 122User B, who follows User A, sees that `kind:31989` event and fetches the `a`-tagged event for the app and handler information.
@@ -127,5 +127,5 @@ User B's client sees the application's `kind:31990` which includes the informati
127Alternatively, users might choose to query directly for `kind:31990` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms or querying high-quality restricted relays to avoid directing users to malicious handlers. 127Alternatively, users might choose to query directly for `kind:31990` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms or querying high-quality restricted relays to avoid directing users to malicious handlers.
128 128
129```json 129```json
130["REQ", <id>, '[{ "kinds": [31990], "#k": [<desired-event-kind>], 'authors': [...] }]'] 130["REQ", <id>, { "kinds": [31990], "#k": [<desired-event-kind>], "authors": [...] }]
131``` 131```
diff --git a/96.md b/96.md
index 2f25351..be70999 100644
--- a/96.md
+++ b/96.md
@@ -301,7 +301,7 @@ Example Response:
301 // ...other metadata 301 // ...other metadata
302 ] 302 ]
303 "content": "haha funny meme", // caption 303 "content": "haha funny meme", // caption
304 "created_at": 1715691130 // upload timestmap 304 "created_at": 1715691130 // upload timestamp
305 }, 305 },
306 ... 306 ...
307 ] 307 ]
diff --git a/98.md b/98.md
index ca52304..be425b2 100644
--- a/98.md
+++ b/98.md
@@ -55,7 +55,8 @@ Using the `Authorization` HTTP header, the `kind 27235` event MUST be `base64` e
55 55
56Example HTTP Authorization header: 56Example HTTP Authorization header:
57``` 57```
58Authorization: Nostr eyJpZCI6ImZlOTY0ZTc1ODkwMzM2MGYyOGQ4NDI0ZDA5MmRhODQ5NGVkMjA3Y2JhODIzMTEwYmUzYTU3ZGZlNGI1Nzg3MzQiLCJwdWJrZXkiOiI2M2ZlNjMxOGRjNTg1ODNjZmUxNjgxMGY4NmRkMDllMThiZmQ3NmFhYmMyNGEwMDgxY2UyODU2ZjMzMDUwNGVkIiwiY29udGVudCI6IiIsImtpbmQiOjI3MjM1LCJjcmVhdGVkX2F0IjoxNjgyMzI3ODUyLCJ0YWdzIjpbWyJ1cmwiLCJodHRwczovL2FwaS5zbm9ydC5zb2NpYWwvYXBpL3YxL241c3AvbGlzdCJdLFsibWV0aG9kIiwiR0VUIl1dLCJzaWciOiI1ZWQ5ZDhlYzk1OGJjODU0Zjk5N2JkYzI0YWMzMzdkMDA1YWYzNzIzMjQ3NDdlZmU0YTAwZTI0ZjRjMzA0MzdmZjRkZDgzMDg2ODRiZWQ0NjdkOWQ2YmUzZTVhNTE3YmI0M2IxNzMyY2M3ZDMzOTQ5YTNhYWY4NjcwNWMyMjE4NCJ9 58Authorization: Nostr
59eyJpZCI6ImZlOTY0ZTc1ODkwMzM2MGYyOGQ4NDI0ZDA5MmRhODQ5NGVkMjA3Y2JhODIzMTEwYmUzYTU3ZGZlNGI1Nzg3MzQiLCJwdWJrZXkiOiI2M2ZlNjMxOGRjNTg1ODNjZmUxNjgxMGY4NmRkMDllMThiZmQ3NmFhYmMyNGEwMDgxY2UyODU2ZjMzMDUwNGVkIiwiY29udGVudCI6IiIsImtpbmQiOjI3MjM1LCJjcmVhdGVkX2F0IjoxNjgyMzI3ODUyLCJ0YWdzIjpbWyJ1IiwiaHR0cHM6Ly9hcGkuc25vcnQuc29jaWFsL2FwaS92MS9uNXNwL2xpc3QiXSxbIm1ldGhvZCIsIkdFVCJdXSwic2lnIjoiNWVkOWQ4ZWM5NThiYzg1NGY5OTdiZGMyNGFjMzM3ZDAwNWFmMzcyMzI0NzQ3ZWZlNGEwMGUyNGY0YzMwNDM3ZmY0ZGQ4MzA4Njg0YmVkNDY3ZDlkNmJlM2U1YTUxN2JiNDNiMTczMmNjN2QzMzk0OWEzYWFmODY3MDVjMjIxODQifQ
59``` 60```
60 61
61## Reference Implementations 62## Reference Implementations
diff --git a/99.md b/99.md
index 93550d8..8948287 100644
--- a/99.md
+++ b/99.md
@@ -8,9 +8,9 @@ Classified Listings
8 8
9This NIP defines `kind:30402`: a parameterized replaceable event to describe classified listings that list any arbitrary product, service, or other thing for sale or offer and includes enough structured metadata to make them useful. 9This NIP defines `kind:30402`: a parameterized replaceable event to describe classified listings that list any arbitrary product, service, or other thing for sale or offer and includes enough structured metadata to make them useful.
10 10
11The category of classifieds includes a very broad range of physical goods, services, work opportunities, rentals, free giveaways, personals, etc. and is distinct from the more strictly structured marketplaces defined in [NIP-15](https://github.com/nostr-protocol/nips/blob/master/15.md) that often sell many units of specific products through very specific channels. 11The category of classifieds includes a very broad range of physical goods, services, work opportunities, rentals, free giveaways, personals, etc. and is distinct from the more strictly structured marketplaces defined in [NIP-15](15.md) that often sell many units of specific products through very specific channels.
12 12
13The structure of these events is very similar to [NIP-23](https://github.com/nostr-protocol/nips/blob/master/23.md) long-form content events. 13The structure of these events is very similar to [NIP-23](23.md) long-form content events.
14 14
15### Draft / Inactive Listings 15### Draft / Inactive Listings
16 16
@@ -26,8 +26,8 @@ The `.pubkey` field of these events are treated as the party creating the listin
26 26
27### Metadata 27### Metadata
28 28
29- For "tags"/"hashtags" (i.e. categories or keywords of relevance for the listing) the `"t"` event tag should be used, as per [NIP-12](https://github.com/nostr-protocol/nips/blob/master/12.md). 29- For "tags"/"hashtags" (i.e. categories or keywords of relevance for the listing) the `"t"` event tag should be used, as per [NIP-12](12.md).
30- For images, whether included in the markdown content or not, clients SHOULD use `image` tags as described in [NIP-58](https://github.com/nostr-protocol/nips/blob/master/58.md). This allows clients to display images in carousel format more easily. 30- For images, whether included in the markdown content or not, clients SHOULD use `image` tags as described in [NIP-58](58.md). This allows clients to display images in carousel format more easily.
31 31
32The following tags, used for structured metadata, are standardized and SHOULD be included. Other tags may be added as necessary. 32The following tags, used for structured metadata, are standardized and SHOULD be included. Other tags may be added as necessary.
33 33
diff --git a/BREAKING.md b/BREAKING.md
index c8255cd..cac3545 100644
--- a/BREAKING.md
+++ b/BREAKING.md
@@ -5,6 +5,10 @@ reverse chronological order.
5 5
6| Date | Commit | NIP | Change | 6| Date | Commit | NIP | Change |
7| ----------- | --------- | -------- | ------ | 7| ----------- | --------- | -------- | ------ |
8| 2024-07-31 | [3ea2f1a4](https://github.com/nostr-protocol/nips/commit/3ea2f1a4) | [NIP-45](45.md) | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) was reverted |
9| 2024-07-30 | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) | [NIP-45](45.md) | NIP-45 was deprecated |
10| 2024-07-26 | [ecee40df](https://github.com/nostr-protocol/nips/commit/ecee40df) | [NIP-19](19.md) | `nrelay` was deprecated |
11| 2024-07-23 | [0227a2cd](https://github.com/nostr-protocol/nips/commit/0227a2cd) | [NIP-01](01.md) | events should be sorted by id after created_at |
8| 2024-06-06 | [58e94b20](https://github.com/nostr-protocol/nips/commit/58e94b20) | [NIP-25](25.md) | [8073c848](https://github.com/nostr-protocol/nips/commit/8073c848) was reverted | 12| 2024-06-06 | [58e94b20](https://github.com/nostr-protocol/nips/commit/58e94b20) | [NIP-25](25.md) | [8073c848](https://github.com/nostr-protocol/nips/commit/8073c848) was reverted |
9| 2024-06-06 | [a6dfc7b5](https://github.com/nostr-protocol/nips/commit/a6dfc7b5) | [NIP-55](55.md) | NIP number was changed | 13| 2024-06-06 | [a6dfc7b5](https://github.com/nostr-protocol/nips/commit/a6dfc7b5) | [NIP-55](55.md) | NIP number was changed |
10| 2024-05-25 | [5d1d1c17](https://github.com/nostr-protocol/nips/commit/5d1d1c17) | [NIP-71](71.md) | 'aes-256-gcm' tag was removed | 14| 2024-05-25 | [5d1d1c17](https://github.com/nostr-protocol/nips/commit/5d1d1c17) | [NIP-71](71.md) | 'aes-256-gcm' tag was removed |
diff --git a/README.md b/README.md
index 99c4245..550888a 100644
--- a/README.md
+++ b/README.md
@@ -74,6 +74,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
74- [NIP-58: Badges](58.md) 74- [NIP-58: Badges](58.md)
75- [NIP-59: Gift Wrap](59.md) 75- [NIP-59: Gift Wrap](59.md)
76- [NIP-65: Relay List Metadata](65.md) 76- [NIP-65: Relay List Metadata](65.md)
77- [NIP-70: Protected Events](70.md)
77- [NIP-71: Video Events](71.md) 78- [NIP-71: Video Events](71.md)
78- [NIP-72: Moderated Communities](72.md) 79- [NIP-72: Moderated Communities](72.md)
79- [NIP-75: Zap Goals](75.md) 80- [NIP-75: Zap Goals](75.md)
@@ -88,112 +89,114 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
88- [NIP-99: Classified Listings](99.md) 89- [NIP-99: Classified Listings](99.md)
89 90
90## Event Kinds 91## Event Kinds
91| kind | description | NIP | 92
92| ------------- | -------------------------- | ------------------------ | 93| kind | description | NIP |
93| `0` | Metadata | [01](01.md) | 94| ------------- | ------------------------------- | -------------------------------------- |
94| `1` | Short Text Note | [01](01.md) | 95| `0` | User Metadata | [01](01.md) |
95| `2` | Recommend Relay | 01 (deprecated) | 96| `1` | Short Text Note | [01](01.md) |
96| `3` | Follows | [02](02.md) | 97| `2` | Recommend Relay | 01 (deprecated) |
97| `4` | Encrypted Direct Messages | [04](04.md) | 98| `3` | Follows | [02](02.md) |
98| `5` | Event Deletion | [09](09.md) | 99| `4` | Encrypted Direct Messages | [04](04.md) |
99| `6` | Repost | [18](18.md) | 100| `5` | Event Deletion | [09](09.md) |
100| `7` | Reaction | [25](25.md) | 101| `6` | Repost | [18](18.md) |
101| `8` | Badge Award | [58](58.md) | 102| `7` | Reaction | [25](25.md) |
102| `9` | Group Chat Message | [29](29.md) | 103| `8` | Badge Award | [58](58.md) |
103| `10` | Group Chat Threaded Reply | [29](29.md) | 104| `9` | Group Chat Message | [29](29.md) |
104| `11` | Group Thread | [29](29.md) | 105| `10` | Group Chat Threaded Reply | [29](29.md) |
105| `12` | Group Thread Reply | [29](29.md) | 106| `11` | Group Thread | [29](29.md) |
106| `13` | Seal | [59](59.md) | 107| `12` | Group Thread Reply | [29](29.md) |
107| `14` | Direct Message | [17](17.md) | 108| `13` | Seal | [59](59.md) |
108| `16` | Generic Repost | [18](18.md) | 109| `14` | Direct Message | [17](17.md) |
109| `40` | Channel Creation | [28](28.md) | 110| `16` | Generic Repost | [18](18.md) |
110| `41` | Channel Metadata | [28](28.md) | 111| `40` | Channel Creation | [28](28.md) |
111| `42` | Channel Message | [28](28.md) | 112| `41` | Channel Metadata | [28](28.md) |
112| `43` | Channel Hide Message | [28](28.md) | 113| `42` | Channel Message | [28](28.md) |
113| `44` | Channel Mute User | [28](28.md) | 114| `43` | Channel Hide Message | [28](28.md) |
114| `818` | Merge Requests | [54](54.md) | 115| `44` | Channel Mute User | [28](28.md) |
115| `1021` | Bid | [15](15.md) | 116| `818` | Merge Requests | [54](54.md) |
116| `1022` | Bid confirmation | [15](15.md) | 117| `1021` | Bid | [15](15.md) |
117| `1040` | OpenTimestamps | [03](03.md) | 118| `1022` | Bid confirmation | [15](15.md) |
118| `1059` | Gift Wrap | [59](59.md) | 119| `1040` | OpenTimestamps | [03](03.md) |
119| `1063` | File Metadata | [94](94.md) | 120| `1059` | Gift Wrap | [59](59.md) |
120| `1311` | Live Chat Message | [53](53.md) | 121| `1063` | File Metadata | [94](94.md) |
121| `1617` | Patches | [34](34.md) | 122| `1311` | Live Chat Message | [53](53.md) |
122| `1621` | Issues | [34](34.md) | 123| `1617` | Patches | [34](34.md) |
123| `1622` | Replies | [34](34.md) | 124| `1621` | Issues | [34](34.md) |
124| `1630`-`1633` | Status | [34](34.md) | 125| `1622` | Replies | [34](34.md) |
125| `1971` | Problem Tracker | [nostrocket][nostrocket] | 126| `1630`-`1633` | Status | [34](34.md) |
126| `1984` | Reporting | [56](56.md) | 127| `1971` | Problem Tracker | [nostrocket][nostrocket] |
127| `1985` | Label | [32](32.md) | 128| `1984` | Reporting | [56](56.md) |
128| `2003` | Torrent | [35](35.md) | 129| `1985` | Label | [32](32.md) |
129| `2004` | Torrent Comment | [35](35.md) | 130| `2003` | Torrent | [35](35.md) |
130| `2022` | Coinjoin Pool | [joinstr][joinstr] | 131| `2004` | Torrent Comment | [35](35.md) |
131| `4550` | Community Post Approval | [72](72.md) | 132| `2022` | Coinjoin Pool | [joinstr][joinstr] |
132| `5000`-`5999` | Job Request | [90](90.md) | 133| `4550` | Community Post Approval | [72](72.md) |
133| `6000`-`6999` | Job Result | [90](90.md) | 134| `5000`-`5999` | Job Request | [90](90.md) |
134| `7000` | Job Feedback | [90](90.md) | 135| `6000`-`6999` | Job Result | [90](90.md) |
135| `9000`-`9030` | Group Control Events | [29](29.md) | 136| `7000` | Job Feedback | [90](90.md) |
136| `9041` | Zap Goal | [75](75.md) | 137| `9000`-`9030` | Group Control Events | [29](29.md) |
137| `9734` | Zap Request | [57](57.md) | 138| `9041` | Zap Goal | [75](75.md) |
138| `9735` | Zap | [57](57.md) | 139| `9734` | Zap Request | [57](57.md) |
139| `9802` | Highlights | [84](84.md) | 140| `9735` | Zap | [57](57.md) |
140| `10000` | Mute list | [51](51.md) | 141| `9802` | Highlights | [84](84.md) |
141| `10001` | Pin list | [51](51.md) | 142| `10000` | Mute list | [51](51.md) |
142| `10002` | Relay List Metadata | [65](65.md) | 143| `10001` | Pin list | [51](51.md) |
143| `10003` | Bookmark list | [51](51.md) | 144| `10002` | Relay List Metadata | [65](65.md) |
144| `10004` | Communities list | [51](51.md) | 145| `10003` | Bookmark list | [51](51.md) |
145| `10005` | Public chats list | [51](51.md) | 146| `10004` | Communities list | [51](51.md) |
146| `10006` | Blocked relays list | [51](51.md) | 147| `10005` | Public chats list | [51](51.md) |
147| `10007` | Search relays list | [51](51.md) | 148| `10006` | Blocked relays list | [51](51.md) |
148| `10009` | User groups | [51](51.md), [29](29.md) | 149| `10007` | Search relays list | [51](51.md) |
149| `10015` | Interests list | [51](51.md) | 150| `10009` | User groups | [51](51.md), [29](29.md) |
150| `10030` | User emoji list | [51](51.md) | 151| `10015` | Interests list | [51](51.md) |
151| `10050` | Relay list to receive DMs | [17](17.md) | 152| `10030` | User emoji list | [51](51.md) |
152| `10096` | File storage server list | [96](96.md) | 153| `10050` | Relay list to receive DMs | [51](51.md), [17](17.md) |
153| `13194` | Wallet Info | [47](47.md) | 154| `10096` | File storage server list | [96](96.md) |
154| `21000` | Lightning Pub RPC | [Lightning.Pub][lnpub] | 155| `13194` | Wallet Info | [47](47.md) |
155| `22242` | Client Authentication | [42](42.md) | 156| `21000` | Lightning Pub RPC | [Lightning.Pub][lnpub] |
156| `23194` | Wallet Request | [47](47.md) | 157| `22242` | Client Authentication | [42](42.md) |
157| `23195` | Wallet Response | [47](47.md) | 158| `23194` | Wallet Request | [47](47.md) |
158| `24133` | Nostr Connect | [46](46.md) | 159| `23195` | Wallet Response | [47](47.md) |
159| `27235` | HTTP Auth | [98](98.md) | 160| `24133` | Nostr Connect | [46](46.md) |
160| `30000` | Follow sets | [51](51.md) | 161| `27235` | HTTP Auth | [98](98.md) |
161| `30001` | Generic lists | [51](51.md) | 162| `30000` | Follow sets | [51](51.md) |
162| `30002` | Relay sets | [51](51.md) | 163| `30001` | Generic lists | [51](51.md) |
163| `30003` | Bookmark sets | [51](51.md) | 164| `30002` | Relay sets | [51](51.md) |
164| `30004` | Curation sets | [51](51.md) | 165| `30003` | Bookmark sets | [51](51.md) |
165| `30005` | Video sets | [51](51.md) | 166| `30004` | Curation sets | [51](51.md) |
166| `30008` | Profile Badges | [58](58.md) | 167| `30005` | Video sets | [51](51.md) |
167| `30009` | Badge Definition | [58](58.md) | 168| `30008` | Profile Badges | [58](58.md) |
168| `30015` | Interest sets | [51](51.md) | 169| `30009` | Badge Definition | [58](58.md) |
169| `30017` | Create or update a stall | [15](15.md) | 170| `30015` | Interest sets | [51](51.md) |
170| `30018` | Create or update a product | [15](15.md) | 171| `30017` | Create or update a stall | [15](15.md) |
171| `30019` | Marketplace UI/UX | [15](15.md) | 172| `30018` | Create or update a product | [15](15.md) |
172| `30020` | Product sold as an auction | [15](15.md) | 173| `30019` | Marketplace UI/UX | [15](15.md) |
173| `30023` | Long-form Content | [23](23.md) | 174| `30020` | Product sold as an auction | [15](15.md) |
174| `30024` | Draft Long-form Content | [23](23.md) | 175| `30023` | Long-form Content | [23](23.md) |
175| `30030` | Emoji sets | [51](51.md) | 176| `30024` | Draft Long-form Content | [23](23.md) |
176| `30063` | Release artifact sets | [51](51.md) | 177| `30030` | Emoji sets | [51](51.md) |
177| `30078` | Application-specific Data | [78](78.md) | 178| `30063` | Release artifact sets | [51](51.md) |
178| `30311` | Live Event | [53](53.md) | 179| `30078` | Application-specific Data | [78](78.md) |
179| `30315` | User Statuses | [38](38.md) | 180| `30311` | Live Event | [53](53.md) |
180| `30402` | Classified Listing | [99](99.md) | 181| `30315` | User Statuses | [38](38.md) |
181| `30403` | Draft Classified Listing | [99](99.md) | 182| `30402` | Classified Listing | [99](99.md) |
182| `30617` | Repository announcements | [34](34.md) | 183| `30403` | Draft Classified Listing | [99](99.md) |
183| `30818` | Wiki article | [54](54.md) | 184| `30617` | Repository announcements | [34](34.md) |
184| `30819` | Redirects | [54](54.md) | 185| `30618` | Repository state announcements | [34](34.md) |
185| `31890` | Feed | [NUD: Custom Feeds](https://wikifreedia.xyz/cip-01/97c70a44366a6535c1) | 186| `30818` | Wiki article | [54](54.md) |
186| `31922` | Date-Based Calendar Event | [52](52.md) | 187| `30819` | Redirects | [54](54.md) |
187| `31923` | Time-Based Calendar Event | [52](52.md) | 188| `31890` | Feed | [NUD: Custom Feeds][NUD: Custom Feeds] |
188| `31924` | Calendar | [52](52.md) | 189| `31922` | Date-Based Calendar Event | [52](52.md) |
189| `31925` | Calendar Event RSVP | [52](52.md) | 190| `31923` | Time-Based Calendar Event | [52](52.md) |
190| `31989` | Handler recommendation | [89](89.md) | 191| `31924` | Calendar | [52](52.md) |
191| `31990` | Handler information | [89](89.md) | 192| `31925` | Calendar Event RSVP | [52](52.md) |
192| `34235` | Video Event | [71](71.md) | 193| `31989` | Handler recommendation | [89](89.md) |
193| `34236` | Short-form Portrait Video Event | [71](71.md) | 194| `31990` | Handler information | [89](89.md) |
194| `34237` | Video View Event | [71](71.md) | 195| `34235` | Video Event | [71](71.md) |
195| `34550` | Community Definition | [72](72.md) | 196| `34236` | Short-form Portrait Video Event | [71](71.md) |
196| `39000-9` | Group metadata events | [29](29.md) | 197| `34237` | Video View Event | [71](71.md) |
198| `34550` | Community Definition | [72](72.md) |
199| `39000-9` | Group metadata events | [29](29.md) |
197 200
198[NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/97c70a44366a6535c1 201[NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/97c70a44366a6535c1
199[nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md 202[nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
@@ -232,7 +235,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
232| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md) | 235| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md) |
233| `a` | coordinates to an event | relay URL | [01](01.md) | 236| `a` | coordinates to an event | relay URL | [01](01.md) |
234| `d` | identifier | -- | [01](01.md) | 237| `d` | identifier | -- | [01](01.md) |
238| `-` | -- | -- | [70](70.md) |
235| `g` | geohash | -- | [52](52.md) | 239| `g` | geohash | -- | [52](52.md) |
240| `h` | group id | -- | [29](29.md) |
236| `i` | identity | proof | [39](39.md) | 241| `i` | identity | proof | [39](39.md) |
237| `k` | kind number (string) | -- | [18](18.md), [25](25.md), [72](72.md) | 242| `k` | kind number (string) | -- | [18](18.md), [25](25.md), [72](72.md) |
238| `l` | label, label namespace | -- | [32](32.md) | 243| `l` | label, label namespace | -- | [32](32.md) |
@@ -259,7 +264,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
259| `imeta` | inline metadata | -- | [92](92.md) | 264| `imeta` | inline metadata | -- | [92](92.md) |
260| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) | 265| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
261| `location` | location string | -- | [52](52.md), [99](99.md) | 266| `location` | location string | -- | [52](52.md), [99](99.md) |
262| `name` | name | -- | [34](34.md), [58](58.md) | 267| `name` | name | -- | [34](34.md), [58](58.md), [72](72.md) |
263| `nonce` | random | difficulty | [13](13.md) | 268| `nonce` | random | difficulty | [13](13.md) |
264| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) | 269| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
265| `price` | price | currency, frequency | [99](99.md) | 270| `price` | price | currency, frequency | [99](99.md) |