upleb.uk

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

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--01.md2
-rw-r--r--02.md2
-rw-r--r--03.md4
-rw-r--r--04.md2
-rw-r--r--05.md2
-rw-r--r--06.md2
-rw-r--r--07.md2
-rw-r--r--08.md2
-rw-r--r--09.md2
-rw-r--r--10.md2
-rw-r--r--11.md167
-rw-r--r--12.md2
-rw-r--r--13.md8
-rw-r--r--14.md10
-rw-r--r--15.md205
-rw-r--r--16.md2
-rw-r--r--18.md2
-rw-r--r--19.md2
-rw-r--r--20.md2
-rw-r--r--21.md2
-rw-r--r--22.md2
-rw-r--r--23.md2
-rw-r--r--24.md2
-rw-r--r--25.md2
-rw-r--r--26.md2
-rw-r--r--27.md2
-rw-r--r--28.md48
-rw-r--r--30.md2
-rw-r--r--31.md2
-rw-r--r--32.md11
-rw-r--r--33.md2
-rw-r--r--36.md28
-rw-r--r--38.md2
-rw-r--r--39.md30
-rw-r--r--40.md26
-rw-r--r--42.md16
-rw-r--r--45.md23
-rw-r--r--46.md2
-rw-r--r--47.md2
-rw-r--r--48.md2
-rw-r--r--50.md2
-rw-r--r--51.md2
-rw-r--r--52.md2
-rw-r--r--53.md32
-rw-r--r--56.md3
-rw-r--r--57.md2
-rw-r--r--58.md2
-rw-r--r--65.md2
-rw-r--r--72.md50
-rw-r--r--75.md19
-rw-r--r--78.md2
-rw-r--r--84.md15
-rw-r--r--89.md97
-rw-r--r--90.md151
-rw-r--r--94.md9
-rw-r--r--98.md30
-rw-r--r--99.md8
-rw-r--r--README.md31
58 files changed, 574 insertions, 517 deletions
diff --git a/01.md b/01.md
index cb4f522..dafea1d 100644
--- a/01.md
+++ b/01.md
@@ -4,7 +4,7 @@ NIP-01
4Basic protocol flow description 4Basic protocol flow description
5------------------------------- 5-------------------------------
6 6
7`draft` `mandatory` `author:fiatjaf` `author:distbit` `author:scsibug` `author:kukks` `author:jb55` `author:semisol` `author:cameri` `author:Giszmo` 7`draft` `mandatory`
8 8
9This NIP defines the basic protocol that should be implemented by everybody. New NIPs may add new optional (or mandatory) fields and messages and features to the structures and flows described here. 9This NIP defines the basic protocol that should be implemented by everybody. New NIPs may add new optional (or mandatory) fields and messages and features to the structures and flows described here.
10 10
diff --git a/02.md b/02.md
index 2f19908..0653d06 100644
--- a/02.md
+++ b/02.md
@@ -4,7 +4,7 @@ NIP-02
4Contact List and Petnames 4Contact List and Petnames
5------------------------- 5-------------------------
6 6
7`final` `optional` `author:fiatjaf` `author:arcbtc` 7`final` `optional`
8 8
9A special event with kind `3`, meaning "contact list" is defined as having a list of `p` tags, one for each of the followed/known profiles one is following. 9A special event with kind `3`, meaning "contact list" is defined as having a list of `p` tags, one for each of the followed/known profiles one is following.
10 10
diff --git a/03.md b/03.md
index 680cc8b..74e010c 100644
--- a/03.md
+++ b/03.md
@@ -4,7 +4,7 @@ NIP-03
4OpenTimestamps Attestations for Events 4OpenTimestamps Attestations for Events
5-------------------------------------- 5--------------------------------------
6 6
7`draft` `optional` `author:fiatjaf` `author:constant` 7`draft` `optional`
8 8
9This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](https://opentimestamps.org/) proof for any other event: 9This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](https://opentimestamps.org/) proof for any other event:
10 10
@@ -20,7 +20,7 @@ This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](
20``` 20```
21 21
22- The OpenTimestamps proof MUST prove the referenced `e` event id as its digest. 22- The OpenTimestamps proof MUST prove the referenced `e` event id as its digest.
23- The `content` MUST be the full content of an `.ots` file containing at least one Bitcoin attestation. This file SHOULD contain a **single** Bitcoin attestation and no reference to "pending" attestations since they are useless in this context. 23- The `content` MUST be the full content of an `.ots` file containing at least one Bitcoin attestation. This file SHOULD contain a **single** Bitcoin attestation (as not more than one valid attestation is necessary and less bytes is better than more) and no reference to "pending" attestations since they are useless in this context.
24 24
25### Example OpenTimestamps proof verification flow 25### Example OpenTimestamps proof verification flow
26 26
diff --git a/04.md b/04.md
index 6e45b74..bf6767b 100644
--- a/04.md
+++ b/04.md
@@ -4,7 +4,7 @@ NIP-04
4Encrypted Direct Message 4Encrypted Direct Message
5------------------------ 5------------------------
6 6
7`final` `optional` `author:arcbtc` 7`final` `optional`
8 8
9A special event with kind `4`, meaning "encrypted direct message". It is supposed to have the following attributes: 9A special event with kind `4`, meaning "encrypted direct message". It is supposed to have the following attributes:
10 10
diff --git a/05.md b/05.md
index 00d69af..6437550 100644
--- a/05.md
+++ b/05.md
@@ -4,7 +4,7 @@ NIP-05
4Mapping Nostr keys to DNS-based internet identifiers 4Mapping Nostr keys to DNS-based internet identifiers
5---------------------------------------------------- 5----------------------------------------------------
6 6
7`final` `optional` `author:fiatjaf` `author:mikedilger` 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` (`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
diff --git a/06.md b/06.md
index a0b4a01..0e50254 100644
--- a/06.md
+++ b/06.md
@@ -4,7 +4,7 @@ NIP-06
4Basic key derivation from mnemonic seed phrase 4Basic key derivation from mnemonic seed phrase
5---------------------------------------------- 5----------------------------------------------
6 6
7`draft` `optional` `author:fiatjaf` 7`draft` `optional`
8 8
9[BIP39](https://bips.xyz/39) is used to generate mnemonic seed words and derive a binary seed from them. 9[BIP39](https://bips.xyz/39) is used to generate mnemonic seed words and derive a binary seed from them.
10 10
diff --git a/07.md b/07.md
index 51ddc16..01af6f4 100644
--- a/07.md
+++ b/07.md
@@ -4,7 +4,7 @@ NIP-07
4`window.nostr` capability for web browsers 4`window.nostr` capability for web browsers
5------------------------------------------ 5------------------------------------------
6 6
7`draft` `optional` `author:fiatjaf` 7`draft` `optional`
8 8
9The `window.nostr` object may be made available by web browsers or extensions and websites or web-apps may make use of it after checking its availability. 9The `window.nostr` object may be made available by web browsers or extensions and websites or web-apps may make use of it after checking its availability.
10 10
diff --git a/08.md b/08.md
index 6793e0b..f4f4341 100644
--- a/08.md
+++ b/08.md
@@ -6,7 +6,7 @@ NIP-08
6Handling Mentions 6Handling Mentions
7----------------- 7-----------------
8 8
9`final` `unrecommended` `optional` `author:fiatjaf` `author:scsibug` 9`final` `unrecommended` `optional`
10 10
11This document standardizes the treatment given by clients of inline mentions of other events and pubkeys inside the content of `text_note`s. 11This document standardizes the treatment given by clients of inline mentions of other events and pubkeys inside the content of `text_note`s.
12 12
diff --git a/09.md b/09.md
index 9dab90f..f92410f 100644
--- a/09.md
+++ b/09.md
@@ -4,7 +4,7 @@ NIP-09
4Event Deletion 4Event Deletion
5-------------- 5--------------
6 6
7`draft` `optional` `author:scsibug` 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` tags, each referencing an event the author is requesting to be deleted.
10 10
diff --git a/10.md b/10.md
index 9c79b4a..5b19fbd 100644
--- a/10.md
+++ b/10.md
@@ -5,7 +5,7 @@ NIP-10
5On "e" and "p" tags in Text Events (kind 1). 5On "e" and "p" tags in Text Events (kind 1).
6-------------------------------------------- 6--------------------------------------------
7 7
8`draft` `optional` `author:unclebobmartin` 8`draft` `optional`
9 9
10## Abstract 10## Abstract
11This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events. It helps clients thread the replies into a tree rooted at the original event. 11This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events. It helps clients thread the replies into a tree rooted at the original event.
diff --git a/11.md b/11.md
index deb6f19..615e796 100644
--- a/11.md
+++ b/11.md
@@ -4,7 +4,7 @@ NIP-11
4Relay Information Document 4Relay Information Document
5--------------------------- 5---------------------------
6 6
7`draft` `optional` `author:scsibug` `author:doc-hex` `author:cameri` 7`draft` `optional`
8 8
9Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay's websocket. 9Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay's websocket.
10 10
@@ -25,42 +25,42 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
25Any field may be omitted, and clients MUST ignore any additional fields they do not understand. Relays MUST accept CORS requests by sending `Access-Control-Allow-Origin`, `Access-Control-Allow-Headers`, and `Access-Control-Allow-Methods` headers. 25Any field may be omitted, and clients MUST ignore any additional fields they do not understand. Relays MUST accept CORS requests by sending `Access-Control-Allow-Origin`, `Access-Control-Allow-Headers`, and `Access-Control-Allow-Methods` headers.
26 26
27Field Descriptions 27Field Descriptions
28----------------- 28------------------
29 29
30### Name ### 30### Name
31 31
32A relay may select a `name` for use in client software. This is a string, and SHOULD be less than 30 characters to avoid client truncation. 32A relay may select a `name` for use in client software. This is a string, and SHOULD be less than 30 characters to avoid client truncation.
33 33
34### Description ### 34### Description
35 35
36Detailed plain-text information about the relay may be contained in the `description` string. It is recommended that this contain no markup, formatting or line breaks for word wrapping, and simply use double newline characters to separate paragraphs. There are no limitations on length. 36Detailed plain-text information about the relay may be contained in the `description` string. It is recommended that this contain no markup, formatting or line breaks for word wrapping, and simply use double newline characters to separate paragraphs. There are no limitations on length.
37 37
38### Pubkey ### 38### Pubkey
39 39
40An administrative contact may be listed with a `pubkey`, in the same format as Nostr events (32-byte hex for a `secp256k1` public key). If a contact is listed, this provides clients with a recommended address to send encrypted direct messages (See `NIP-04`) to a system administrator. Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance. 40An administrative contact may be listed with a `pubkey`, in the same format as Nostr events (32-byte hex for a `secp256k1` public key). If a contact is listed, this provides clients with a recommended address to send encrypted direct messages (See `NIP-04`) to a system administrator. Expected uses of this address are to report abuse or illegal content, file bug reports, or request other technical assistance.
41 41
42Relay operators have no obligation to respond to direct messages. 42Relay operators have no obligation to respond to direct messages.
43 43
44### Contact ### 44### Contact
45 45
46An alternative contact may be listed under the `contact` field as well, with the same purpose as `pubkey`. Use of a Nostr public key and direct message SHOULD be preferred over this. Contents of this field SHOULD be a URI, using schemes such as `mailto` or `https` to provide users with a means of contact. 46An alternative contact may be listed under the `contact` field as well, with the same purpose as `pubkey`. Use of a Nostr public key and direct message SHOULD be preferred over this. Contents of this field SHOULD be a URI, using schemes such as `mailto` or `https` to provide users with a means of contact.
47 47
48### Supported NIPs ### 48### Supported NIPs
49 49
50As the Nostr protocol evolves, some functionality may only be available by relays that implement a specific `NIP`. This field is an array of the integer identifiers of `NIP`s that are implemented in the relay. Examples would include `1`, for `"NIP-01"` and `9`, for `"NIP-09"`. Client-side `NIPs` SHOULD NOT be advertised, and can be ignored by clients. 50As the Nostr protocol evolves, some functionality may only be available by relays that implement a specific `NIP`. This field is an array of the integer identifiers of `NIP`s that are implemented in the relay. Examples would include `1`, for `"NIP-01"` and `9`, for `"NIP-09"`. Client-side `NIPs` SHOULD NOT be advertised, and can be ignored by clients.
51 51
52### Software ### 52### Software
53 53
54The relay server implementation MAY be provided in the `software` attribute. If present, this MUST be a URL to the project's homepage. 54The relay server implementation MAY be provided in the `software` attribute. If present, this MUST be a URL to the project's homepage.
55 55
56### Version ### 56### Version
57 57
58The relay MAY choose to publish its software version as a string attribute. The string format is defined by the relay implementation. It is recommended this be a version number or commit identifier. 58The relay MAY choose to publish its software version as a string attribute. The string format is defined by the relay implementation. It is recommended this be a version number or commit identifier.
59 59
60Extra Fields 60Extra Fields
61----------------- 61------------
62 62
63### Server Limitations ### 63### Server Limitations
64 64
65These are limitations imposed by the relay on clients. Your client 65These are limitations imposed by the relay on clients. Your client
66should expect that requests which exceed these *practical* limitations 66should expect that requests which exceed these *practical* limitations
@@ -68,22 +68,22 @@ are rejected or fail immediately.
68 68
69```json 69```json
70{ 70{
71...
72 "limitation": { 71 "limitation": {
73 "max_message_length": 16384, 72 "max_message_length": 16384,
74 "max_subscriptions": 20, 73 "max_subscriptions": 20,
75 "max_filters": 100, 74 "max_filters": 100,
76 "max_limit": 5000, 75 "max_limit": 5000,
77 "max_subid_length": 100, 76 "max_subid_length": 100,
78 "max_event_tags": 100, 77 "max_event_tags": 100,
79 "max_content_length": 8196, 78 "max_content_length": 8196,
80 "min_pow_difficulty": 30, 79 "min_pow_difficulty": 30,
81 "auth_required": true, 80 "auth_required": true,
82 "payment_required": true, 81 "payment_required": true,
83 "created_at_lower_limit":31536000, 82 "restricted_writes": true,
84 "created_at_upper_limit":3, 83 "created_at_lower_limit": 31536000,
85 } 84 "created_at_upper_limit": 3
86... 85 },
86 ...
87} 87}
88``` 88```
89 89
@@ -125,11 +125,17 @@ Even if set to False, authentication may be required for specific actions.
125 125
126- `payment_required`: this relay requires payment before a new connection may perform any action. 126- `payment_required`: this relay requires payment before a new connection may perform any action.
127 127
128- `restricted_writes`: this relay requires some kind of condition to be fulfilled in order to
129accept events (not necessarily, but including `payment_required` and `min_pow_difficulty`).
130This should only be set to `true` when users are expected to know the relay policy before trying
131to write to it -- like belonging to a special pubkey-based whitelist or writing only events of
132a specific niche kind or content. Normal anti-spam heuristics, for example, do not qualify.
133
128- `created_at_lower_limit`: 'created_at' lower limit as defined in [NIP-22](22.md) 134- `created_at_lower_limit`: 'created_at' lower limit as defined in [NIP-22](22.md)
129 135
130- `created_at_upper_limit`: 'created_at' upper limit as defined in [NIP-22](22.md) 136- `created_at_upper_limit`: 'created_at' upper limit as defined in [NIP-22](22.md)
131 137
132### Event Retention ### 138### Event Retention
133 139
134There may be a cost associated with storing data forever, so relays 140There may be a cost associated with storing data forever, so relays
135may wish to state retention times. The values stated here are defaults 141may wish to state retention times. The values stated here are defaults
@@ -142,14 +148,12 @@ all, and preferably an error will be provided when those are received.
142 148
143```json 149```json
144{ 150{
145...
146 "retention": [ 151 "retention": [
147 { "kinds": [0, 1, [5, 7], [40, 49]], "time": 3600 }, 152 {"kinds": [0, 1, [5, 7], [40, 49]], "time": 3600},
148 { "kinds": [[40000, 49999]], "time": 100 }, 153 {"kinds": [[40000, 49999]], "time": 100},
149 { "kinds": [[30000, 39999]], "count": 1000 }, 154 {"kinds": [[30000, 39999]], "count": 1000},
150 { "time": 3600, "count": 10000 } 155 {"time": 3600, "count": 10000}
151 ] 156 ]
152...
153} 157}
154``` 158```
155 159
@@ -165,8 +169,7 @@ support their protocol quickly via a single HTTP fetch.
165 169
166There is no need to specify retention times for _ephemeral events_ since they are not retained. 170There is no need to specify retention times for _ephemeral events_ since they are not retained.
167 171
168 172### Content Limitations
169### Content Limitations ###
170 173
171Some relays may be governed by the arbitrary laws of a nation state. This 174Some relays may be governed by the arbitrary laws of a nation state. This
172may limit what content can be stored in cleartext on those relays. All 175may limit what content can be stored in cleartext on those relays. All
@@ -185,9 +188,8 @@ flexibility is up to the client software.
185 188
186```json 189```json
187{ 190{
188...
189 "relay_countries": [ "CA", "US" ], 191 "relay_countries": [ "CA", "US" ],
190... 192 ...
191} 193}
192``` 194```
193 195
@@ -199,7 +201,7 @@ country of the legal entities who own the relay, so it's very
199likely a number of countries are involved. 201likely a number of countries are involved.
200 202
201 203
202### Community Preferences ### 204### Community Preferences
203 205
204For public text notes at least, a relay may try to foster a 206For public text notes at least, a relay may try to foster a
205local community. This would encourage users to follow the global 207local community. This would encourage users to follow the global
@@ -208,11 +210,10 @@ To support this goal, relays MAY specify some of the following values.
208 210
209```json 211```json
210{ 212{
211... 213 "language_tags": ["en", "en-419"],
212 "language_tags": [ "en", "en-419" ], 214 "tags": ["sfw-only", "bitcoin-only", "anime"],
213 "tags": [ "sfw-only", "bitcoin-only", "anime" ],
214 "posting_policy": "https://example.com/posting-policy.html", 215 "posting_policy": "https://example.com/posting-policy.html",
215... 216 ...
216} 217}
217``` 218```
218 219
@@ -239,59 +240,75 @@ detail and legal terms. Use the `tags` field to signify limitations
239on content, or topics to be discussed, which could be machine 240on content, or topics to be discussed, which could be machine
240processed by appropriate client software. 241processed by appropriate client software.
241 242
242### Pay-To-Relay ### 243### Pay-to-Relay
243 244
244Relays that require payments may want to expose their fee schedules. 245Relays that require payments may want to expose their fee schedules.
245 246
246```json 247```json
247{ 248{
248...
249 "payments_url": "https://my-relay/payments", 249 "payments_url": "https://my-relay/payments",
250 "fees": { 250 "fees": {
251 "admission": [{ "amount": 1000000, "unit": "msats" }], 251 "admission": [{ "amount": 1000000, "unit": "msats" }],
252 "subscription": [{ "amount": 5000000, "unit": "msats", "period": 2592000 }], 252 "subscription": [{ "amount": 5000000, "unit": "msats", "period": 2592000 }],
253 "publication": [{ "kinds": [4], "amount": 100, "unit": "msats" }], 253 "publication": [{ "kinds": [4], "amount": 100, "unit": "msats" }],
254 }, 254 },
255... 255 ...
256} 256}
257``` 257```
258 258
259### Icon ### 259### Icon
260 260
261A URL pointing to an image to be used as an icon for the relay. Recommended to be squared in shape. 261A URL pointing to an image to be used as an icon for the relay. Recommended to be squared in shape.
262 262
263```json 263```json
264{ 264{
265...
266 "icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg", 265 "icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg",
267... 266 ...
268} 267}
269``` 268```
270 269
271### Examples ### 270### Examples
272As of 2 May 2023 the following `curl` command provided these results. 271
273 272As of 2 May 2023 the following command provided these results:
274 >curl -H "Accept: application/nostr+json" https://eden.nostr.land 273
275 274```
276 {"name":"eden.nostr.land", 275~> curl -H "Accept: application/nostr+json" https://eden.nostr.land | jq
277 "description":"Eden Nostr Land - Toronto 1-01", 276
278 "pubkey":"00000000827ffaa94bfea288c3dfce4422c794fbb96625b6b31e9049f729d700", 277{
279 "contact":"me@ricardocabral.io", 278 "description": "nostr.land family of relays (us-or-01)",
280 "supported_nips":[1,2,4,9,11,12,15,16,20,22,26,28,33,40], 279 "name": "nostr.land",
281 "supported_nip_extensions":["11a"], 280 "pubkey": "52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd",
282 "software":"git+https://github.com/Cameri/nostream.git", 281 "software": "custom",
283 "version":"1.22.6", 282 "supported_nips": [
284 "limitation":{"max_message_length":1048576, 283 1,
285 "max_subscriptions":10, 284 2,
286 "max_filters":2500, 285 4,
287 "max_limit":5000, 286 9,
288 "max_subid_length":256, 287 11,
289 "max_event_tags":2500, 288 12,
290 "max_content_length":65536, 289 16,
291 "min_pow_difficulty":0, 290 20,
292 "auth_required":false, 291 22,
293 "payment_required":true}, 292 28,
294 "payments_url":"https://eden.nostr.land/invoices", 293 33,
295 "fees":{"admission":[{"amount":5000000,"unit":"msats"}], 294 40
296 "publication":[]}}, 295 ],
297 "icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg" 296 "version": "1.0.1",
297 "limitation": {
298 "payment_required": true,
299 "max_message_length": 65535,
300 "max_event_tags": 2000,
301 "max_subscriptions": 20,
302 "auth_required": false
303 },
304 "payments_url": "https://eden.nostr.land",
305 "fees": {
306 "subscription": [
307 {
308 "amount": 2500000,
309 "unit": "msats",
310 "period": 2592000
311 }
312 ]
313 },
314}
diff --git a/12.md b/12.md
index 9357977..bf0eda9 100644
--- a/12.md
+++ b/12.md
@@ -4,6 +4,6 @@ NIP-12
4Generic Tag Queries 4Generic Tag Queries
5------------------- 5-------------------
6 6
7`final` `mandatory` `author:scsibug` `author:fiatjaf` 7`final` `mandatory`
8 8
9Moved to [NIP-01](01.md). 9Moved to [NIP-01](01.md).
diff --git a/13.md b/13.md
index 0178733..53c4d1b 100644
--- a/13.md
+++ b/13.md
@@ -4,7 +4,7 @@ NIP-13
4Proof of Work 4Proof of Work
5------------- 5-------------
6 6
7`draft` `optional` `author:jb55` `author:cameri` 7`draft` `optional`
8 8
9This NIP defines a way to generate and interpret Proof of Work for nostr notes. Proof of Work (PoW) is a way to add a proof of computational work to a note. This is a bearer proof that all relays and clients can universally validate with a small amount of code. This proof can be used as a means of spam deterrence. 9This NIP defines a way to generate and interpret Proof of Work for nostr notes. Proof of Work (PoW) is a way to add a proof of computational work to a note. This is a bearer proof that all relays and clients can universally validate with a small amount of code. This proof can be used as a means of spam deterrence.
10 10
@@ -35,11 +35,7 @@ Example mined note
35 "created_at": 1651794653, 35 "created_at": 1651794653,
36 "kind": 1, 36 "kind": 1,
37 "tags": [ 37 "tags": [
38 [ 38 ["nonce", "776797", "21"]
39 "nonce",
40 "776797",
41 "21"
42 ]
43 ], 39 ],
44 "content": "It's just me mining my own business", 40 "content": "It's just me mining my own business",
45 "sig": "284622fc0a3f4f1303455d5175f7ba962a3300d136085b9566801bc2e0699de0c7e31e44c81fb40ad9049173742e904713c3594a1da0fc5d2382a25c11aba977" 41 "sig": "284622fc0a3f4f1303455d5175f7ba962a3300d136085b9566801bc2e0699de0c7e31e44c81fb40ad9049173742e904713c3594a1da0fc5d2382a25c11aba977"
diff --git a/14.md b/14.md
index 7384394..480c4c5 100644
--- a/14.md
+++ b/14.md
@@ -4,16 +4,18 @@ NIP-14
4Subject tag in Text events 4Subject tag in Text events
5-------------------------- 5--------------------------
6 6
7`draft` `optional` `author:unclebobmartin` 7`draft` `optional`
8 8
9This NIP defines the use of the "subject" tag in text (kind: 1) events. 9This NIP defines the use of the "subject" tag in text (kind: 1) events.
10(implemented in more-speech) 10(implemented in more-speech)
11 11
12`["subject": <string>]` 12```json
13["subject": <string>]
14```
13 15
14Browsers often display threaded lists of messages. The contents of the subject tag can be used in such lists, instead of the more ad hoc approach of using the first few words of the message. This is very similar to the way email browsers display lists of incoming emails by subject rather than by contents. 16Browsers often display threaded lists of messages. The contents of the subject tag can be used in such lists, instead of the more ad hoc approach of using the first few words of the message. This is very similar to the way email browsers display lists of incoming emails by subject rather than by contents.
15 17
16When replying to a message with a subject, clients SHOULD replicate the subject tag. Clients MAY adorn the subject to denote 18When replying to a message with a subject, clients SHOULD replicate the subject tag. Clients MAY adorn the subject to denote
17that it is a reply. e.g. by prepending "Re:". 19that it is a reply. e.g. by prepending "Re:".
18 20
19Subjects should generally be shorter than 80 chars. Long subjects will likely be trimmed by clients. 21Subjects should generally be shorter than 80 chars. Long subjects will likely be trimmed by clients.
diff --git a/15.md b/15.md
index 68d28ff..51b7792 100644
--- a/15.md
+++ b/15.md
@@ -1,14 +1,14 @@
1NIP-15 1NIP-15
2====== 2======
3 3
4Nostr Marketplace (for resilient marketplaces) 4Nostr Marketplace
5----------------------------------- 5-----------------
6 6
7`draft` `optional` `author:fiatjaf` `author:benarc` `author:motorina0` `author:talvasconcelos` 7`draft` `optional`
8 8
9> Based on https://github.com/lnbits/Diagon-Alley 9Based on https://github.com/lnbits/Diagon-Alley.
10 10
11> Implemented 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
13## Terms 13## Terms
14 14
@@ -35,29 +35,30 @@ The `merchant` admin software can be purely clientside, but for `convenience` an
35A merchant can publish these events: 35A merchant can publish these events:
36| Kind | | Description | 36| Kind | | Description |
37| --------- | ------------------ | --------------------------------------------------------------------------------------------------------------- | 37| --------- | ------------------ | --------------------------------------------------------------------------------------------------------------- |
38| `0 ` | `set_meta` | The merchant description (similar with any `nostr` public key). | 38| `0` | `set_meta` | The merchant description (similar with any `nostr` public key). |
39| `30017` | `set_stall` | Create or update a stall. | 39| `30017` | `set_stall` | Create or update a stall. |
40| `30018` | `set_product` | Create or update a product. | 40| `30018` | `set_product` | Create or update a product. |
41| `4 ` | `direct_message` | Communicate with the customer. The messages can be plain-text or JSON. | 41| `4` | `direct_message` | Communicate with the customer. The messages can be plain-text or JSON. |
42| `5 ` | `delete` | Delete a product or a stall. | 42| `5` | `delete` | Delete a product or a stall. |
43 43
44### Event `30017`: Create or update a stall. 44### Event `30017`: Create or update a stall.
45 45
46**Event Content**: 46**Event Content**
47
47```json 48```json
48{ 49{
49 "id": <String, UUID generated by the merchant. Sequential IDs (`0`, `1`, `2`...) are discouraged>, 50 "id": <string, id generated by the merchant. Sequential IDs (`0`, `1`, `2`...) are discouraged>,
50 "name": <String, stall name>, 51 "name": <string, stall name>,
51 "description": <String (optional), stall description>, 52 "description": <string (optional), stall description>,
52 "currency": <String, currency used>, 53 "currency": <string, currency used>,
53 "shipping": [ 54 "shipping": [
54 { 55 {
55 "id": <String, UUID of the shipping zone, generated by the merchant>, 56 "id": <string, id of the shipping zone, generated by the merchant>,
56 "name": <String (optional), zone name>, 57 "name": <string (optional), zone name>,
57 "cost": <float, base cost for shipping. The currency is defined at the stall level>, 58 "cost": <float, base cost for shipping. The currency is defined at the stall level>,
58 "regions": [<String, regions included in this zone>], 59 "regions": [<string, regions included in this zone>],
59 } 60 }
60 ] 61 ]
61} 62}
62``` 63```
63 64
@@ -70,34 +71,39 @@ Fields that are not self-explanatory:
70 - each shipping zone contains the base cost for orders made to that shipping zone, but a specific shipping cost per 71 - each shipping zone contains the base cost for orders made to that shipping zone, but a specific shipping cost per
71 product can also be specified if the shipping cost for that product is higher than what's specified by the base cost. 72 product can also be specified if the shipping cost for that product is higher than what's specified by the base cost.
72 73
73**Event Tags**: 74**Event Tags**
75
74```json 76```json
75 "tags": [["d", <String, id of stall]] 77{
78 "tags": [["d", <string, id of stall]],
79 ...
80}
76``` 81```
77 - the `d` tag is required, its value MUST be the same as the stall `id`. 82 - the `d` tag is required, its value MUST be the same as the stall `id`.
78 83
79### Event `30018`: Create or update a product 84### Event `30018`: Create or update a product
80 85
81**Event Content**: 86**Event Content**
87
82```json 88```json
83{ 89{
84 "id": <String, UUID generated by the merchant.Sequential IDs (`0`, `1`, `2`...) are discouraged>, 90 "id": <string, id generated by the merchant (sequential ids are discouraged)>,
85 "stall_id": <String, UUID of the stall to which this product belong to>, 91 "stall_id": <string, id of the stall to which this product belong to>,
86 "name": <String, product name>, 92 "name": <string, product name>,
87 "description": <String (optional), product description>, 93 "description": <string (optional), product description>,
88 "images": <[String], array of image URLs, optional>, 94 "images": <[string], array of image URLs, optional>,
89 "currency": <String, currency used>, 95 "currency": <string, currency used>,
90 "price": <float, cost of product>, 96 "price": <float, cost of product>,
91 "quantity": <int or null, available items>, 97 "quantity": <int or null, available items>,
92 "specs": [ 98 "specs": [
93 [<String, spec key>, <String, spec value>] 99 [<string, spec key>, <string, spec value>]
94 ], 100 ],
95 "shipping": [ 101 "shipping": [
96 { 102 {
97 "id": <String, UUID of the shipping zone. Must match one of the zones defined for the stall>, 103 "id": <string, id of the shipping zone (must match one of the zones defined for the stall)>,
98 "cost": <float, extra cost for shipping. The currency is defined at the stall level>, 104 "cost": <float, extra cost for shipping. The currency is defined at the stall level>,
99 } 105 }
100 ] 106 ]
101} 107}
102``` 108```
103 109
@@ -114,16 +120,18 @@ Fields that are not self-explanatory:
114 - the `id` should match the id of the shipping zone, as defined in the `shipping` field of the stall 120 - the `id` should match the id of the shipping zone, as defined in the `shipping` field of the stall
115 - to calculate the total cost of shipping for an order, the user will choose a shipping option during checkout, and then the client must consider this costs: 121 - to calculate the total cost of shipping for an order, the user will choose a shipping option during checkout, and then the client must consider this costs:
116 - the `base cost from the stall` for the chosen shipping option 122 - the `base cost from the stall` for the chosen shipping option
117 - the result of multiplying the product units by the `shipping costs specified in the product`, if any. 123 - the result of multiplying the product units by the `shipping costs specified in the product`, if any.
124
125**Event Tags**
118 126
119**Event Tags**:
120```json 127```json
121 "tags": [ 128 "tags": [
122 ["d", <String, id of product], 129 ["d", <string, id of product],
123 ["t", <String (optional), product category], 130 ["t", <string (optional), product category],
124 ["t", <String (optional), product category], 131 ["t", <string (optional), product category],
125 ... 132 ...
126 ] 133 ],
134 ...
127``` 135```
128 136
129 - the `d` tag is required, its value MUST be the same as the product `id`. 137 - the `d` tag is required, its value MUST be the same as the product `id`.
@@ -147,23 +155,23 @@ The below json goes in content of [NIP04](https://github.com/nostr-protocol/nips
147 155
148```json 156```json
149{ 157{
150 "id": <String, UUID generated by the customer>, 158 "id": <string, id generated by the customer>,
151 "type": 0, 159 "type": 0,
152 "name": <String (optional), ???>, 160 "name": <string (optional), ???>,
153 "address": <String (optional), for physical goods an address should be provided> 161 "address": <string (optional), for physical goods an address should be provided>
154 "message": "<String (optional), message for merchant>, 162 "message": "<string (optional), message for merchant>,
155 "contact": { 163 "contact": {
156 "nostr": <32-bytes hex of a pubkey>, 164 "nostr": <32-bytes hex of a pubkey>,
157 "phone": <String (optional), if the customer wants to be contacted by phone>, 165 "phone": <string (optional), if the customer wants to be contacted by phone>,
158 "email": <String (optional), if the customer wants to be contacted by email>, 166 "email": <string (optional), if the customer wants to be contacted by email>,
159 }, 167 },
160 "items": [ 168 "items": [
161 { 169 {
162 "product_id": <String, UUID of the product>, 170 "product_id": <string, id of the product>,
163 "quantity": <int, how many products the customer is ordering> 171 "quantity": <int, how many products the customer is ordering>
164 } 172 }
165 ], 173 ],
166 "shipping_id": <String, UUID of the shipping zone> 174 "shipping_id": <string, id of the shipping zone>
167} 175}
168 176
169``` 177```
@@ -186,23 +194,23 @@ The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/ni
186 194
187```json 195```json
188{ 196{
189 "id": <String, UUID of the order>, 197 "id": <string, id of the order>,
190 "type": 1, 198 "type": 1,
191 "message": <String, message to customer, optional>, 199 "message": <string, message to customer, optional>,
192 "payment_options": [ 200 "payment_options": [
193 { 201 {
194 "type": <String, option type>, 202 "type": <string, option type>,
195 "link": <String, url, btc address, ln invoice, etc> 203 "link": <string, url, btc address, ln invoice, etc>
196 }, 204 },
197 { 205 {
198 "type": <String, option type>, 206 "type": <string, option type>,
199 "link": <String, url, btc address, ln invoice, etc> 207 "link": <string, url, btc address, ln invoice, etc>
200 }, 208 },
201 { 209 {
202 "type": <String, option type>, 210 "type": <string, option type>,
203 "link": <String, url, btc address, ln invoice, etc> 211 "link": <string, url, btc address, ln invoice, etc>
204 } 212 }
205 ] 213 ]
206} 214}
207``` 215```
208 216
@@ -214,11 +222,11 @@ The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/ni
214 222
215```json 223```json
216{ 224{
217 "id": <String, UUID of the order>, 225 "id": <string, id of the order>,
218 "type": 2, 226 "type": 2,
219 "message": <String, message to customer>, 227 "message": <string, message to customer>,
220 "paid": <Bool, true/false has received payment>, 228 "paid": <bool: has received payment>,
221 "shipped": <Bool, true/false has been shipped>, 229 "shipped": <bool: has been shipped>,
222} 230}
223``` 231```
224## Customize Marketplace 232## Customize Marketplace
@@ -226,19 +234,20 @@ Create a customized user experience using the `naddr` from [NIP-19](https://gith
226 234
227### Event `30019`: Create or update marketplace UI/UX 235### Event `30019`: Create or update marketplace UI/UX
228 236
229**Event Content**: 237**Event Content**
238
230```json 239```json
231{ 240{
232 "name": <String (optional), market name>, 241 "name": <string (optional), market name>,
233 "about": <String (optional), market description>, 242 "about": <string (optional), market description>,
234 "ui": { 243 "ui": {
235 "picture": <String (optional), market logo image URL>, 244 "picture": <string (optional), market logo image URL>,
236 "banner": <String (optional), market logo banner URL>, 245 "banner": <string (optional), market logo banner URL>,
237 "theme": <String (optional), market theme>, 246 "theme": <string (optional), market theme>,
238 "darkMode": <Bool, true/false> 247 "darkMode": <bool, true/false>
239 }, 248 },
240 "merchants": <[String] (optional), array of pubkeys>, 249 "merchants": [array of pubkeys (optional)],
241 ... 250 ...
242} 251}
243``` 252```
244 253
diff --git a/16.md b/16.md
index 78ec708..0032083 100644
--- a/16.md
+++ b/16.md
@@ -4,6 +4,6 @@ NIP-16
4Event Treatment 4Event Treatment
5--------------- 5---------------
6 6
7`final` `mandatory` `author:Semisol` 7`final` `mandatory`
8 8
9Moved to [NIP-01](01.md). 9Moved to [NIP-01](01.md).
diff --git a/18.md b/18.md
index 75c4100..ba96c89 100644
--- a/18.md
+++ b/18.md
@@ -4,7 +4,7 @@ NIP-18
4Reposts 4Reposts
5------- 5-------
6 6
7`draft` `optional` `author:jb55` `author:fiatjaf` `author:arthurfranca` 7`draft` `optional`
8 8
9A repost is a `kind 6` event that is used to signal to followers 9A repost is a `kind 6` event that is used to signal to followers
10that a `kind 1` text note is worth reading. 10that a `kind 1` text note is worth reading.
diff --git a/19.md b/19.md
index cd989e2..ef80887 100644
--- a/19.md
+++ b/19.md
@@ -4,7 +4,7 @@ NIP-19
4bech32-encoded entities 4bech32-encoded entities
5----------------------- 5-----------------------
6 6
7`draft` `optional` `author:jb55` `author:fiatjaf` `author:Semisol` 7`draft` `optional`
8 8
9This NIP standardizes bech32-formatted strings that can be used to display keys, ids and other information in clients. These formats are not meant to be used anywhere in the core protocol, they are only meant for displaying to users, copy-pasting, sharing, rendering QR codes and inputting data. 9This NIP standardizes bech32-formatted strings that can be used to display keys, ids and other information in clients. These formats are not meant to be used anywhere in the core protocol, they are only meant for displaying to users, copy-pasting, sharing, rendering QR codes and inputting data.
10 10
diff --git a/20.md b/20.md
index ec6127a..6feed6a 100644
--- a/20.md
+++ b/20.md
@@ -4,6 +4,6 @@ NIP-20
4Command Results 4Command Results
5--------------- 5---------------
6 6
7`final` `mandatory` `author:jb55` 7`final` `mandatory`
8 8
9Moved to [NIP-01](01.md). 9Moved to [NIP-01](01.md).
diff --git a/21.md b/21.md
index 6246eb4..6ed141a 100644
--- a/21.md
+++ b/21.md
@@ -4,7 +4,7 @@ NIP-21
4`nostr:` URI scheme 4`nostr:` URI scheme
5------------------- 5-------------------
6 6
7`draft` `optional` `author:fiatjaf` 7`draft` `optional`
8 8
9This NIP standardizes the usage of a common URI scheme for maximum interoperability and openness in the network. 9This NIP standardizes the usage of a common URI scheme for maximum interoperability and openness in the network.
10 10
diff --git a/22.md b/22.md
index f595ebf..06af493 100644
--- a/22.md
+++ b/22.md
@@ -4,7 +4,7 @@ NIP-22
4Event `created_at` Limits 4Event `created_at` Limits
5------------------------- 5-------------------------
6 6
7`draft` `optional` `author:jeffthibault` `author:Giszmo` 7`draft` `optional`
8 8
9Relays may define both upper and lower limits within which they will consider an event's `created_at` to be acceptable. Both the upper and lower limits MUST be unix timestamps in seconds as defined in [NIP-01](01.md). 9Relays may define both upper and lower limits within which they will consider an event's `created_at` to be acceptable. Both the upper and lower limits MUST be unix timestamps in seconds as defined in [NIP-01](01.md).
10 10
diff --git a/23.md b/23.md
index 76c0a69..382df83 100644
--- a/23.md
+++ b/23.md
@@ -4,7 +4,7 @@ NIP-23
4Long-form Content 4Long-form Content
5----------------- 5-----------------
6 6
7`draft` `optional` `author:fiatjaf` 7`draft` `optional`
8 8
9This NIP defines `kind:30023` (a _parameterized replaceable event_) for long-form text content, generally referred to as "articles" or "blog posts". `kind:30024` has the same structure as `kind:30023` and is used to save long form drafts. 9This NIP defines `kind:30023` (a _parameterized replaceable event_) for long-form text content, generally referred to as "articles" or "blog posts". `kind:30024` has the same structure as `kind:30023` and is used to save long form drafts.
10 10
diff --git a/24.md b/24.md
index b88d990..f830b68 100644
--- a/24.md
+++ b/24.md
@@ -4,7 +4,7 @@ NIP-24
4Extra metadata fields and tags 4Extra metadata fields and tags
5------------------------------ 5------------------------------
6 6
7`draft` `optional` `author:fiatjaf` 7`draft` `optional`
8 8
9This NIP defines extra optional fields added to events. 9This NIP defines extra optional fields added to events.
10 10
diff --git a/25.md b/25.md
index 7b29140..3b4aa59 100644
--- a/25.md
+++ b/25.md
@@ -5,7 +5,7 @@ NIP-25
5Reactions 5Reactions
6--------- 6---------
7 7
8`draft` `optional` `author:jb55` 8`draft` `optional`
9 9
10A reaction is a `kind 7` event that is used to react to other events. 10A reaction is a `kind 7` event that is used to react to other events.
11 11
diff --git a/26.md b/26.md
index 59cf807..86c46e1 100644
--- a/26.md
+++ b/26.md
@@ -4,7 +4,7 @@ NIP-26
4Delegated Event Signing 4Delegated Event Signing
5----- 5-----
6 6
7`draft` `optional` `author:markharding` `author:minds` 7`draft` `optional`
8 8
9This NIP defines how events can be delegated so that they can be signed by other keypairs. 9This NIP defines how events can be delegated so that they can be signed by other keypairs.
10 10
diff --git a/27.md b/27.md
index 6d76120..efd2c12 100644
--- a/27.md
+++ b/27.md
@@ -4,7 +4,7 @@ NIP-27
4Text Note References 4Text Note References
5-------------------- 5--------------------
6 6
7`draft` `optional` `author:arthurfranca` `author:hodlbod` `author:fiatjaf` 7`draft` `optional`
8 8
9This document standardizes the treatment given by clients of inline references of other events and profiles inside the `.content` of any event that has readable text in its `.content` (such as kinds 1 and 30023). 9This document standardizes the treatment given by clients of inline references of other events and profiles inside the `.content` of any event that has readable text in its `.content` (such as kinds 1 and 30023).
10 10
diff --git a/28.md b/28.md
index 62ab398..2dcf800 100644
--- a/28.md
+++ b/28.md
@@ -5,7 +5,7 @@ NIP-28
5Public Chat 5Public Chat
6----------- 6-----------
7 7
8`draft` `optional` `author:ChristopherDavid` `author:fiatjaf` `author:jb55` `author:Cameri` 8`draft` `optional`
9 9
10This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation. 10This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation.
11 11
@@ -27,8 +27,8 @@ In the channel creation `content` field, Client SHOULD include basic channel met
27 27
28```json 28```json
29{ 29{
30 "content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\"}", 30 "content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\"}",
31 ... 31 ...
32} 32}
33``` 33```
34 34
@@ -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. 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.
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
@@ -53,9 +53,9 @@ Clients SHOULD use [NIP-10](10.md) marked "e" tags to recommend a relay.
53 53
54```json 54```json
55{ 55{
56 "content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\"}", 56 "content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\"}",
57 "tags": [["e", <channel_create_event_id>, <relay-url>]], 57 "tags": [["e", <channel_create_event_id>, <relay-url>]],
58 ... 58 ...
59} 59}
60``` 60```
61 61
@@ -72,9 +72,9 @@ Root message:
72 72
73```json 73```json
74{ 74{
75 "content": <string>, 75 "content": <string>,
76 "tags": [["e", <kind_40_event_id>, <relay-url>, "root"]], 76 "tags": [["e", <kind_40_event_id>, <relay-url>, "root"]],
77 ... 77 ...
78} 78}
79``` 79```
80 80
@@ -82,14 +82,14 @@ Reply to another message:
82 82
83```json 83```json
84{ 84{
85 "content": <string>, 85 "content": <string>,
86 "tags": [ 86 "tags": [
87 ["e", <kind_40_event_id>, <relay-url>, "root"], 87 ["e", <kind_40_event_id>, <relay-url>, "root"],
88 ["e", <kind_42_event_id>, <relay-url>, "reply"], 88 ["e", <kind_42_event_id>, <relay-url>, "reply"],
89 ["p", <pubkey>, <relay-url>], 89 ["p", <pubkey>, <relay-url>],
90 ... 90 ...
91 ], 91 ],
92 ... 92 ...
93} 93}
94``` 94```
95 95
@@ -108,9 +108,9 @@ Clients MAY hide event 42s for other users other than the user who sent the even
108 108
109```json 109```json
110{ 110{
111 "content": "{\"reason\": \"Dick pic\"}", 111 "content": "{\"reason\": \"Dick pic\"}",
112 "tags": [["e", <kind_42_event_id>]], 112 "tags": [["e", <kind_42_event_id>]],
113 ... 113 ...
114} 114}
115``` 115```
116 116
@@ -126,9 +126,9 @@ Clients MAY hide event 42s for users other than the user who sent the event 44.
126 126
127```json 127```json
128{ 128{
129 "content": "{\"reason\": \"Posting dick pics\"}", 129 "content": "{\"reason\": \"Posting dick pics\"}",
130 "tags": [["p", <pubkey>]], 130 "tags": [["p", <pubkey>]],
131 ... 131 ...
132} 132}
133``` 133```
134 134
diff --git a/30.md b/30.md
index ffc5aeb..5a6f84d 100644
--- a/30.md
+++ b/30.md
@@ -4,7 +4,7 @@ NIP-30
4Custom Emoji 4Custom Emoji
5------------ 5------------
6 6
7`draft` `optional` `author:alexgleason` 7`draft` `optional`
8 8
9Custom emoji may be added to **kind 0** and **kind 1** events by including one or more `"emoji"` tags, in the form: 9Custom emoji may be added to **kind 0** and **kind 1** events by including one or more `"emoji"` tags, in the form:
10 10
diff --git a/31.md b/31.md
index e77ae34..ee92052 100644
--- a/31.md
+++ b/31.md
@@ -4,7 +4,7 @@ NIP-31
4Dealing with unknown event kinds 4Dealing with unknown event kinds
5-------------------------------- 5--------------------------------
6 6
7`draft` `optional` `author:pablof7z` `author:fiatjaf` 7`draft` `optional`
8 8
9When creating a new custom event kind that is part of a custom protocol and isn't meant to be read as text (like `kind:1`), clients should use an `alt` tag to write a short human-readable plaintext summary of what that event is about. 9When creating a new custom event kind that is part of a custom protocol and isn't meant to be read as text (like `kind:1`), clients should use an `alt` tag to write a short human-readable plaintext summary of what that event is about.
10 10
diff --git a/32.md b/32.md
index f8dc002..be4e872 100644
--- a/32.md
+++ b/32.md
@@ -4,7 +4,7 @@ NIP-32
4Labeling 4Labeling
5--------- 5---------
6 6
7`draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay` 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, 9A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases,
10including distributed moderation, collection management, license assignment, and content classification. 10including distributed moderation, collection management, license assignment, and content classification.
@@ -64,7 +64,8 @@ A suggestion that multiple pubkeys be associated with the `permies` topic.
64 ["l", "permies", "#t"], 64 ["l", "permies", "#t"],
65 ["p", <pubkey1>, <relay_url>], 65 ["p", <pubkey1>, <relay_url>],
66 ["p", <pubkey2>, <relay_url>] 66 ["p", <pubkey2>, <relay_url>]
67 ] 67 ],
68 ...
68} 69}
69``` 70```
70 71
@@ -78,7 +79,8 @@ A report flagging violence toward a human being as defined by ontology.example.c
78 ["l", "VI-hum", "com.example.ontology"], 79 ["l", "VI-hum", "com.example.ontology"],
79 ["p", <pubkey1>, <relay_url>], 80 ["p", <pubkey1>, <relay_url>],
80 ["p", <pubkey2>, <relay_url>] 81 ["p", <pubkey2>, <relay_url>]
81 ] 82 ],
83 ...
82} 84}
83``` 85```
84 86
@@ -92,6 +94,7 @@ A moderation suggestion for a chat event.
92 ["l", "approve", "nip28.moderation"], 94 ["l", "approve", "nip28.moderation"],
93 ["e", <kind40_event_id>, <relay_url>] 95 ["e", <kind40_event_id>, <relay_url>]
94 ], 96 ],
97 ...
95} 98}
96``` 99```
97 100
@@ -105,6 +108,7 @@ Assignment of a license to an event.
105 ["l", "MIT", "license"], 108 ["l", "MIT", "license"],
106 ["e", <event_id>, <relay_url>] 109 ["e", <event_id>, <relay_url>]
107 ], 110 ],
111 ...
108} 112}
109``` 113```
110 114
@@ -119,6 +123,7 @@ is labeling their note as being related to Milan, Italy using ISO 3166-2.
119 ["l", "IT-MI", "ISO-3166-2"] 123 ["l", "IT-MI", "ISO-3166-2"]
120 ], 124 ],
121 "content": "It's beautiful here in Milan!", 125 "content": "It's beautiful here in Milan!",
126 ...
122} 127}
123``` 128```
124 129
diff --git a/33.md b/33.md
index 1e7a9fc..337a1f9 100644
--- a/33.md
+++ b/33.md
@@ -4,6 +4,6 @@ NIP-33
4Parameterized Replaceable Events 4Parameterized Replaceable Events
5-------------------------------- 5--------------------------------
6 6
7`final` `mandatory` `author:Semisol` `author:Kukks` `author:Cameri` `author:Giszmo` 7`final` `mandatory`
8 8
9Moved to [NIP-01](01.md). 9Moved to [NIP-01](01.md).
diff --git a/36.md b/36.md
index 6d1cf63..b10262c 100644
--- a/36.md
+++ b/36.md
@@ -4,7 +4,7 @@ NIP-36
4Sensitive Content / Content Warning 4Sensitive Content / Content Warning
5----------------------------------- 5-----------------------------------
6 6
7`draft` `optional` `author:fernandolguevara` 7`draft` `optional`
8 8
9The `content-warning` tag enables users to specify if the event's content needs to be approved by readers to be shown. 9The `content-warning` tag enables users to specify if the event's content needs to be approved by readers to be shown.
10Clients can hide the content until the user acts on it. 10Clients can hide the content until the user acts on it.
@@ -24,18 +24,18 @@ options:
24 24
25```json 25```json
26{ 26{
27 "pubkey": "<pub-key>", 27 "pubkey": "<pub-key>",
28 "created_at": 1000000000, 28 "created_at": 1000000000,
29 "kind": 1, 29 "kind": 1,
30 "tags": [ 30 "tags": [
31 ["t", "hastag"], 31 ["t", "hastag"],
32 ["L", "content-warning"], 32 ["L", "content-warning"],
33 ["l", "reason", "content-warning"], 33 ["l", "reason", "content-warning"],
34 ["L", "social.nos.ontology"], 34 ["L", "social.nos.ontology"],
35 ["l", "NS-nud", "social.nos.ontology"], 35 ["l", "NS-nud", "social.nos.ontology"],
36 ["content-warning", "reason"] /* reason is optional */ 36 ["content-warning", "<optional reason>"]
37 ], 37 ],
38 "content": "sensitive content with #hastag\n", 38 "content": "sensitive content with #hastag\n",
39 "id": "<event-id>" 39 "id": "<event-id>"
40} 40}
41``` 41```
diff --git a/38.md b/38.md
index f1eddcd..911d5b1 100644
--- a/38.md
+++ b/38.md
@@ -5,7 +5,7 @@ NIP-38
5User Statuses 5User Statuses
6-------------- 6--------------
7 7
8`draft` `optional` `author:jb55` 8`draft` `optional`
9 9
10## Abstract 10## Abstract
11 11
diff --git a/39.md b/39.md
index b84603c..c819e43 100644
--- a/39.md
+++ b/39.md
@@ -4,7 +4,7 @@ NIP-39
4External Identities in Profiles 4External Identities in Profiles
5------------------------------- 5-------------------------------
6 6
7`draft` `optional` `author:pseudozach` `author:Semisol` 7`draft` `optional`
8 8
9## Abstract 9## Abstract
10 10
@@ -15,15 +15,13 @@ Nostr protocol users may have other online identities such as usernames, profile
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 contents in addition to name, about, picture fields as included in [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md):
16```json 16```json
17{ 17{
18 "id": <id>, 18 "tags": [
19 "pubkey": <pubkey>, 19 ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
20 ... 20 ["i", "twitter:semisol_public", "1619358434134196225"],
21 "tags": [ 21 ["i", "mastodon:bitcoinhackers.org/@semisol", "109775066355589974"]
22 ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"], 22 ["i", "telegram:1087295469", "nostrdirectory/770"]
23 ["i", "twitter:semisol_public", "1619358434134196225"], 23 ],
24 ["i", "mastodon:bitcoinhackers.org/@semisol", "109775066355589974"] 24 ...
25 ["i", "telegram:1087295469", "nostrdirectory/770"]
26 ]
27} 25}
28``` 26```
29 27
@@ -31,9 +29,9 @@ An `i` tag will have two parameters, which are defined as the following:
311. `platform:identity`: This is the platform name (for example `github`) and the identity on that platform (for example `semisol`) joined together with `:`. 291. `platform:identity`: This is the platform name (for example `github`) and the identity on that platform (for example `semisol`) joined together with `:`.
322. `proof`: String or object that points to the proof of owning this identity. 302. `proof`: String or object that points to the proof of owning this identity.
33 31
34Clients SHOULD process any `i` tags with more than 2 values for future extensibility. 32Clients SHOULD process any `i` tags with more than 2 values for future extensibility.
35Identity provider names SHOULD only include `a-z`, `0-9` and the characters `._-/` and MUST NOT include `:`. 33Identity provider names SHOULD only include `a-z`, `0-9` and the characters `._-/` and MUST NOT include `:`.
36Identity names SHOULD be normalized if possible by replacing uppercase letters with lowercase letters, and if there are multiple aliases for an entity the primary one should be used. 34Identity names SHOULD be normalized if possible by replacing uppercase letters with lowercase letters, and if there are multiple aliases for an entity the primary one should be used.
37 35
38## Claim types 36## Claim types
39 37
@@ -41,14 +39,14 @@ Identity names SHOULD be normalized if possible by replacing uppercase letters w
41 39
42Identity: A GitHub username. 40Identity: A GitHub username.
43 41
44Proof: A GitHub Gist ID. This Gist should be created by `<identity>` with a single file that has the text `Verifying that I control the following Nostr public key: <npub encoded public key>`. 42Proof: A GitHub Gist ID. This Gist should be created by `<identity>` with a single file that has the text `Verifying that I control the following Nostr public key: <npub encoded public key>`.
45This can be located at `https://gist.github.com/<identity>/<proof>`. 43This can be located at `https://gist.github.com/<identity>/<proof>`.
46 44
47### `twitter` 45### `twitter`
48 46
49Identity: A Twitter username. 47Identity: A Twitter username.
50 48
51Proof: A Tweet ID. The tweet should be posted by `<identity>` and have the text `Verifying my account on nostr My Public Key: "<npub encoded public key>"`. 49Proof: A Tweet ID. The tweet should be posted by `<identity>` and have the text `Verifying my account on nostr My Public Key: "<npub encoded public key>"`.
52This can be located at `https://twitter.com/<identity>/status/<proof>`. 50This can be located at `https://twitter.com/<identity>/status/<proof>`.
53 51
54### `mastodon` 52### `mastodon`
@@ -62,5 +60,5 @@ This can be located at `https://<identity>/<proof>`.
62 60
63Identity: A Telegram user ID. 61Identity: A Telegram user ID.
64 62
65Proof: A string in the format `<ref>/<id>` which points to a message published in the public channel or group with name `<ref>` and message ID `<id>`. This message should be sent by user ID `<identity>` and have the text `Verifying that I control the following Nostr public key: "<npub encoded public key>"`. 63Proof: A string in the format `<ref>/<id>` which points to a message published in the public channel or group with name `<ref>` and message ID `<id>`. This message should be sent by user ID `<identity>` and have the text `Verifying that I control the following Nostr public key: "<npub encoded public key>"`.
66This can be located at `https://t.me/<proof>`. 64This can be located at `https://t.me/<proof>`.
diff --git a/40.md b/40.md
index 32680db..909747f 100644
--- a/40.md
+++ b/40.md
@@ -2,9 +2,9 @@ NIP-40
2====== 2======
3 3
4Expiration Timestamp 4Expiration Timestamp
5----------------------------------- 5--------------------
6 6
7`draft` `optional` `author:0xtlt` 7`draft` `optional`
8 8
9The `expiration` tag enables users to specify a unix timestamp at which the message SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays. 9The `expiration` tag enables users to specify a unix timestamp at which the message SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays.
10 10
@@ -20,14 +20,14 @@ values:
20 20
21```json 21```json
22{ 22{
23 "pubkey": "<pub-key>", 23 "pubkey": "<pub-key>",
24 "created_at": 1000000000, 24 "created_at": 1000000000,
25 "kind": 1, 25 "kind": 1,
26 "tags": [ 26 "tags": [
27 ["expiration", "1600000000"] 27 ["expiration", "1600000000"]
28 ], 28 ],
29 "content": "This message will expire at the specified timestamp and be deleted by relays.\n", 29 "content": "This message will expire at the specified timestamp and be deleted by relays.\n",
30 "id": "<event-id>" 30 "id": "<event-id>"
31} 31}
32``` 32```
33 33
@@ -43,9 +43,9 @@ Clients SHOULD ignore events that have expired.
43Relay Behavior 43Relay Behavior
44-------------- 44--------------
45 45
46Relays MAY NOT delete expired messages immediately on expiration and MAY persist them indefinitely. 46Relays MAY NOT delete expired messages immediately on expiration and MAY persist them indefinitely.
47Relays SHOULD NOT send expired events to clients, even if they are stored. 47Relays SHOULD NOT send expired events to clients, even if they are stored.
48Relays SHOULD drop any events that are published to them if they are expired. 48Relays SHOULD drop any events that are published to them if they are expired.
49An expiration timestamp does not affect storage of ephemeral events. 49An expiration timestamp does not affect storage of ephemeral events.
50 50
51Suggested Use Cases 51Suggested Use Cases
diff --git a/42.md b/42.md
index 9b0c45b..e380e89 100644
--- a/42.md
+++ b/42.md
@@ -4,7 +4,7 @@ NIP-42
4Authentication of clients to relays 4Authentication of clients to relays
5----------------------------------- 5-----------------------------------
6 6
7`draft` `optional` `author:Semisol` `author:fiatjaf` 7`draft` `optional`
8 8
9This NIP defines a way for clients to authenticate to relays by signing an ephemeral event. 9This NIP defines a way for clients to authenticate to relays by signing an ephemeral event.
10 10
@@ -24,13 +24,13 @@ A relay may want to require clients to authenticate to access restricted resourc
24This NIP defines a new message, `AUTH`, which relays can send when they support authentication and clients can send to relays when they want 24This NIP defines a new message, `AUTH`, which relays can send when they support authentication and clients can send to relays when they want
25to authenticate. When sent by relays, the message is of the following form: 25to authenticate. When sent by relays, the message is of the following form:
26 26
27``` 27```json
28["AUTH", <challenge-string>] 28["AUTH", <challenge-string>]
29``` 29```
30 30
31And, when sent by clients, of the following form: 31And, when sent by clients, of the following form:
32 32
33``` 33```json
34["AUTH", <signed-event-json>] 34["AUTH", <signed-event-json>]
35``` 35```
36 36
@@ -41,16 +41,12 @@ Relays MUST exclude `kind: 22242` events from being broadcasted to any client.
41 41
42```json 42```json
43{ 43{
44 "id": "...",
45 "pubkey": "...",
46 "created_at": 1669695536,
47 "kind": 22242, 44 "kind": 22242,
48 "tags": [ 45 "tags": [
49 ["relay", "wss://relay.example.com/"], 46 ["relay", "wss://relay.example.com/"],
50 ["challenge", "challengestringhere"] 47 ["challenge", "challengestringhere"]
51 ], 48 ],
52 "content": "", 49 ...
53 "sig": "..."
54} 50}
55``` 51```
56 52
@@ -67,13 +63,13 @@ is expected to last for the duration of the WebSocket connection.
67Upon receiving a message from an unauthenticated user it can't fulfill without authentication, a relay may choose to notify the client. For 63Upon receiving a message from an unauthenticated user it can't fulfill without authentication, a relay may choose to notify the client. For
68that it can use a `NOTICE` or `OK` message with a standard prefix `"restricted: "` that is readable both by humans and machines, for example: 64that it can use a `NOTICE` or `OK` message with a standard prefix `"restricted: "` that is readable both by humans and machines, for example:
69 65
70``` 66```json
71["NOTICE", "restricted: we can't serve DMs to unauthenticated users, does your client implement NIP-42?"] 67["NOTICE", "restricted: we can't serve DMs to unauthenticated users, does your client implement NIP-42?"]
72``` 68```
73 69
74or it can return an `OK` message noting the reason an event was not written using the same prefix: 70or it can return an `OK` message noting the reason an event was not written using the same prefix:
75 71
76``` 72```json
77["OK", <event-id>, false, "restricted: we do not accept events from unauthenticated users, please sign up at https://example.com/"] 73["OK", <event-id>, false, "restricted: we do not accept events from unauthenticated users, please sign up at https://example.com/"]
78``` 74```
79 75
diff --git a/45.md b/45.md
index 7b11950..998b952 100644
--- a/45.md
+++ b/45.md
@@ -4,7 +4,7 @@ NIP-45
4Event Counts 4Event Counts
5-------------- 5--------------
6 6
7`draft` `optional` `author:staab` 7`draft` `optional`
8 8
9Relays may support the verb `COUNT`, which provides a mechanism for obtaining event counts. 9Relays may support the verb `COUNT`, which provides a mechanism for obtaining event counts.
10 10
@@ -16,29 +16,36 @@ Some queries a client may want to execute against connected relays are prohibiti
16 16
17This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result. 17This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
18 18
19``` 19```json
20["COUNT", <subscription_id>, <filters JSON>...] 20["COUNT", <subscription_id>, <filters JSON>...]
21``` 21```
22 22
23Counts are returned using a `COUNT` response in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements. 23Counts are returned using a `COUNT` response in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
24In case a relay uses probabilistic counts, it MAY indicate it in the response with `approximate` key i.e. `{"count": <integer>, "approximate": <true|false>}`. 24In case a relay uses probabilistic counts, it MAY indicate it in the response with `approximate` key i.e. `{"count": <integer>, "approximate": <true|false>}`.
25 25
26``` 26```json
27["COUNT", <subscription_id>, {"count": <integer>}] 27["COUNT", <subscription_id>, {"count": <integer>}]
28``` 28```
29 29
30Examples: 30## Examples:
31 31
32``` 32### Followers count
33# Followers count 33
34```json
34["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}] 35["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
35["COUNT", <subscription_id>, {"count": 238}] 36["COUNT", <subscription_id>, {"count": 238}]
37```
36 38
37# Count posts and reactions 39### Count posts and reactions
40
41```json
38["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}] 42["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
39["COUNT", <subscription_id>, {"count": 5}] 43["COUNT", <subscription_id>, {"count": 5}]
44```
40 45
41# Count posts approximately 46### Count posts approximately
47
48```
42["COUNT", <subscription_id>, {"kinds": [1]}] 49["COUNT", <subscription_id>, {"kinds": [1]}]
43["COUNT", <subscription_id>, {"count": 93412452, "approximate": true}] 50["COUNT", <subscription_id>, {"count": 93412452, "approximate": true}]
44``` 51```
diff --git a/46.md b/46.md
index 90fa1a0..5318541 100644
--- a/46.md
+++ b/46.md
@@ -4,7 +4,7 @@ NIP-46
4Nostr Connect 4Nostr Connect
5------------------------ 5------------------------
6 6
7`draft` `optional` `author:tiero` `author:giowe` `author:vforvalerio87` 7`draft` `optional`
8 8
9## Rationale 9## Rationale
10 10
diff --git a/47.md b/47.md
index b6a4f2b..d4b7c1f 100644
--- a/47.md
+++ b/47.md
@@ -4,7 +4,7 @@ NIP-47
4Nostr Wallet Connect 4Nostr Wallet Connect
5-------------------- 5--------------------
6 6
7`draft` `optional` `author:kiwiidb` `author:bumi` `author:semisol` `author:vitorpamplona` 7`draft` `optional`
8 8
9## Rationale 9## Rationale
10 10
diff --git a/48.md b/48.md
index 8f22781..2f03e00 100644
--- a/48.md
+++ b/48.md
@@ -4,7 +4,7 @@ NIP-48
4Proxy Tags 4Proxy Tags
5---------- 5----------
6 6
7`draft` `optional` `author:alexgleason` 7`draft` `optional`
8 8
9Nostr events bridged from other protocols such as ActivityPub can link back to the source object by including a `"proxy"` tag, in the form: 9Nostr events bridged from other protocols such as ActivityPub can link back to the source object by including a `"proxy"` tag, in the form:
10 10
diff --git a/50.md b/50.md
index 5bda355..2bdf1ff 100644
--- a/50.md
+++ b/50.md
@@ -4,7 +4,7 @@ NIP-50
4Search Capability 4Search Capability
5----------------- 5-----------------
6 6
7`draft` `optional` `author:brugeman` `author:mikedilger` `author:fiatjaf` 7`draft` `optional`
8 8
9## Abstract 9## Abstract
10 10
diff --git a/51.md b/51.md
index 54c0920..f5a9a74 100644
--- a/51.md
+++ b/51.md
@@ -4,7 +4,7 @@ NIP-51
4Lists 4Lists
5----- 5-----
6 6
7`draft` `optional` `author:fiatjaf` `author:arcbtc` `author:monlovesmango` `author:eskema` `author:gzuuus` 7`draft` `optional`
8 8
9This NIP defines lists of things that users can create. Lists can contain references to anything, and these references can be **public** or **private**. 9This NIP defines lists of things that users can create. Lists can contain references to anything, and these references can be **public** or **private**.
10 10
diff --git a/52.md b/52.md
index 6950744..15cc8fc 100644
--- a/52.md
+++ b/52.md
@@ -4,7 +4,7 @@ NIP-52
4Calendar Events 4Calendar Events
5--------------- 5---------------
6 6
7`draft` `optional` `author:tyiu` 7`draft` `optional`
8 8
9This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are _parameterized replaceable_ and deletable per [NIP-09](09.md). 9This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are _parameterized replaceable_ and deletable per [NIP-09](09.md).
10 10
diff --git a/53.md b/53.md
index b3d416b..d3cc0af 100644
--- a/53.md
+++ b/53.md
@@ -4,19 +4,19 @@ NIP-53
4Live Activities 4Live Activities
5--------------- 5---------------
6 6
7`draft` `optional` `author:vitorpamplona` `author:v0l` 7`draft` `optional`
8
9## Abstract
10 8
11Service providers want to offer live activities to the Nostr network in such a way that participants can easily logged and queried by clients. This NIP describes a general framework to advertise the involvement of pubkeys in such live activities. 9Service providers want to offer live activities to the Nostr network in such a way that participants can easily logged and queried by clients. This NIP describes a general framework to advertise the involvement of pubkeys in such live activities.
12 10
13# Live Event 11## Concepts
12
13### Live Event
14 14
15A special event with `kind:30311` "Live Event" is defined as a _parameterized replaceable event_ of public `p` tags. Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity. 15A special event with `kind:30311` "Live Event" is defined as a _parameterized replaceable event_ of public `p` tags. Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity.
16 16
17For example: 17For example:
18 18
19```js 19```json
20{ 20{
21 "kind": 30311, 21 "kind": 30311,
22 "tags": [ 22 "tags": [
@@ -38,7 +38,7 @@ For example:
38 ["relays", "wss://one.com", "wss://two.com", ...] 38 ["relays", "wss://one.com", "wss://two.com", ...]
39 ], 39 ],
40 "content": "", 40 "content": "",
41 ...other fields 41 ...
42} 42}
43``` 43```
44 44
@@ -52,7 +52,7 @@ Live Activity management clients are expected to constantly update `kind:30311`
52 52
53The activity MUST be linked to using the [NIP-19](19.md) `naddr` code along with the `a` tag. 53The activity MUST be linked to using the [NIP-19](19.md) `naddr` code along with the `a` tag.
54 54
55## Proof of Agreement to Participate 55### Proof of Agreement to Participate
56 56
57Event owners can add proof as the 5th term in each `p` tag to clarify the participant's agreement in joining the event. The proof is a signed SHA256 of the complete `a` Tag of the event (`kind:pubkey:dTag`) by each `p`'s private key, encoded in hex. 57Event owners can add proof as the 5th term in each `p` tag to clarify the participant's agreement in joining the event. The proof is a signed SHA256 of the complete `a` Tag of the event (`kind:pubkey:dTag`) by each `p`'s private key, encoded in hex.
58 58
@@ -60,30 +60,28 @@ Clients MAY only display participants if the proof is available or MAY display p
60 60
61This feature is important to avoid malicious event owners adding large account holders to the event, without their knowledge, to lure their followers into the malicious owner's trap. 61This feature is important to avoid malicious event owners adding large account holders to the event, without their knowledge, to lure their followers into the malicious owner's trap.
62 62
63# Live Chat Message 63### Live Chat Message
64 64
65Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity with a `root` marker. Other Kind-1 tags such as `reply` and `mention` can also be used. 65Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity with a `root` marker. Other Kind-1 tags such as `reply` and `mention` can also be used.
66 66
67```js 67```json
68{ 68{
69 "id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>",
70 "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
71 "created_at": "<Unix timestamp in seconds>",
72 "kind": 1311, 69 "kind": 1311,
73 "tags": [ 70 "tags": [
74 ["a", "30311:<Community event author pubkey>:<d-identifier of the community>", "<Optional relay url>", "root"], 71 ["a", "30311:<Community event author pubkey>:<d-identifier of the community>", "<Optional relay url>", "root"],
75 ], 72 ],
76 "content": "Zaps to live streams is beautiful." 73 "content": "Zaps to live streams is beautiful.",
74 ...
77} 75}
78``` 76```
79 77
80# Use Cases 78## Use Cases
81 79
82Common use cases include meeting rooms/workshops, watch-together activities, or event spaces, such as [live.snort.social](https://live.snort.social) and [nostrnests.com](https://nostrnests.com). 80Common use cases include meeting rooms/workshops, watch-together activities, or event spaces, such as [live.snort.social](https://live.snort.social) and [nostrnests.com](https://nostrnests.com).
83 81
84# Example 82## Example
85 83
86Live Streaming 84### Live Streaming
87 85
88```json 86```json
89{ 87{
@@ -107,7 +105,7 @@ Live Streaming
107} 105}
108``` 106```
109 107
110Live Streaming chat message 108### Live Streaming chat message
111 109
112```json 110```json
113{ 111{
diff --git a/56.md b/56.md
index 259118d..a2861e3 100644
--- a/56.md
+++ b/56.md
@@ -1,11 +1,10 @@
1
2NIP-56 1NIP-56
3====== 2======
4 3
5Reporting 4Reporting
6--------- 5---------
7 6
8`draft` `optional` `author:jb55` 7`draft` `optional`
9 8
10A report is a `kind 1984` note that is used to report other notes for spam, 9A report is a `kind 1984` note that is used to report other notes for spam,
11illegal and explicit content. 10illegal and explicit content.
diff --git a/57.md b/57.md
index 849c869..2b2c97b 100644
--- a/57.md
+++ b/57.md
@@ -4,7 +4,7 @@ NIP-57
4Lightning Zaps 4Lightning Zaps
5-------------- 5--------------
6 6
7`draft` `optional` `author:jb55` `author:kieran` 7`draft` `optional`
8 8
9This NIP defines two new event types for recording lightning payments between users. `9734` is a `zap request`, representing a payer's request to a recipient's lightning wallet for an invoice. `9735` is a `zap receipt`, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a `zap request` has been paid. 9This NIP defines two new event types for recording lightning payments between users. `9734` is a `zap request`, representing a payer's request to a recipient's lightning wallet for an invoice. `9735` is a `zap receipt`, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a `zap request` has been paid.
10 10
diff --git a/58.md b/58.md
index ccabc7b..9725c82 100644
--- a/58.md
+++ b/58.md
@@ -4,7 +4,7 @@ NIP-58
4Badges 4Badges
5------ 5------
6 6
7`draft` `optional` `author:cameri` 7`draft` `optional`
8 8
9Three special events are used to define, award and display badges in 9Three special events are used to define, award and display badges in
10user profiles: 10user profiles:
diff --git a/65.md b/65.md
index cdfe9bf..4a6f5a1 100644
--- a/65.md
+++ b/65.md
@@ -4,7 +4,7 @@ NIP-65
4Relay List Metadata 4Relay List Metadata
5------------------- 5-------------------
6 6
7`draft` `optional` `author:mikedilger` `author:vitorpamplona` 7`draft` `optional`
8 8
9Defines a replaceable event using `kind:10002` to advertise preferred relays for discovering a user's content and receiving fresh content from others. 9Defines a replaceable event using `kind:10002` to advertise preferred relays for discovering a user's content and receiving fresh content from others.
10 10
diff --git a/72.md b/72.md
index 599a4c4..c0fffff 100644
--- a/72.md
+++ b/72.md
@@ -4,22 +4,20 @@ NIP-72
4Moderated Communities (Reddit Style) 4Moderated Communities (Reddit Style)
5------------------------------------ 5------------------------------------
6 6
7`draft` `optional` `author:vitorpamplona` `author:arthurfranca` 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 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.
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.
14 14
15```json 15```json
16{ 16{
17 "id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>",
18 "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
19 "created_at": <Unix timestamp in seconds>, 17 "created_at": <Unix timestamp in seconds>,
20 "kind": 34550, 18 "kind": 34550,
21 "tags": [ 19 "tags": [
22 ["d", "<Community name>"], 20 ["d", "<community-d-identifier>"],
23 ["description", "<Community description>"], 21 ["description", "<Community description>"],
24 ["image", "<Community image url>", "<Width>x<Height>"], 22 ["image", "<Community image url>", "<Width>x<Height>"],
25 23
@@ -35,24 +33,23 @@ The goal of this NIP is to create moderator-approved public communities around a
35 ["relay", "<relay where to send and receive requests>", "requests"], 33 ["relay", "<relay where to send and receive requests>", "requests"],
36 ["relay", "<relay where to send and receive approvals>", "approvals"], 34 ["relay", "<relay where to send and receive approvals>", "approvals"],
37 ["relay", "<relay where to post requests to and fetch approvals from>"] 35 ["relay", "<relay where to post requests to and fetch approvals from>"]
38 ] 36 ],
37 ...
39} 38}
40``` 39```
41 40
42# New Post Request 41# New Post Request
43 42
44Any Nostr event can be a post request. Clients MUST add the community's `a` tag to the new post event in order to be presented for the moderator's approval. 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.
45 44
46```json 45```json
47{ 46{
48 "id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>",
49 "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
50 "created_at": <Unix timestamp in seconds>,
51 "kind": 1, 47 "kind": 1,
52 "tags": [ 48 "tags": [
53 ["a", "34550:<Community event author pubkey>:<d-identifier of the community>", "<Optional relay url>"], 49 ["a", "34550:<community event author pubkey>:<community-d-identifier>", "<optional-relay-url>"],
54 ], 50 ],
55 "content": "<My content>" 51 "content": "hello world",
52 ...
56} 53}
57``` 54```
58 55
@@ -64,17 +61,16 @@ The post-approval event MUST include `a` tags of the communities the moderator i
64 61
65```json 62```json
66{ 63{
67 "id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>",
68 "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>", 64 "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
69 "created_at": <Unix timestamp in seconds>,
70 "kind": 4550, 65 "kind": 4550,
71 "tags": [ 66 "tags": [
72 ["a", "34550:<Community event author pubkey>:<d-identifier of the community>", "<Optional relay url>"], 67 ["a", "34550:<event-author-pubkey>:<community-d-identifier>", "<optional-relay-url>"],
73 ["e", "<Post Request ID>", "<Optional relay url>"], 68 ["e", "<post-id>", "<optional-relay-url>"],
74 ["p", "<Post Request Author ID>", "<Optional relay url>"], 69 ["p", "<port-author-pubkey>", "<optional-relay-url>"],
75 ["k", "<New Post Request kind>"], 70 ["k", "<post-request-kind>"]
76 ], 71 ],
77 "content": "<New Post Request JSON>" 72 "content": "<the full approved event, JSON-encoded>",
73 ...
78} 74}
79``` 75```
80 76
@@ -90,12 +86,16 @@ Community clients SHOULD display posts that have been approved by at least 1 mod
90 86
91The following filter displays the approved posts. 87The following filter displays the approved posts.
92 88
93```js 89```json
94{ 90[
95 "authors": ["<Author pubkey>", "<Moderator1 pubkey>", "<Moderator2 pubkey>", "<Moderator3 pubkey>", ...], 91 "REQ",
96 "kinds": [4550], 92 "_",
97 "#a": ["34550:<Community event author pubkey>:<d-identifier of the community>"], 93 {
98} 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``` 99```
100 100
101Clients MAY hide approvals by blocked moderators at the user's request. 101Clients MAY hide approvals by blocked moderators at the user's request.
diff --git a/75.md b/75.md
index 6c8cb7b..f3cf5d0 100644
--- a/75.md
+++ b/75.md
@@ -1,8 +1,10 @@
1# NIP-75 1NIP-75
2======
2 3
3## Zap Goals 4Zap Goals
5---------
4 6
5`draft` `optional` `author:verbiricha` 7`draft` `optional`
6 8
7This NIP defines an event for creating fundraising goals. Users can contribute funds towards the goal by zapping the goal event. 9This NIP defines an event for creating fundraising goals. Users can contribute funds towards the goal by zapping the goal event.
8 10
@@ -27,7 +29,7 @@ Example event:
27 ["amount", "210000"], 29 ["amount", "210000"],
28 ], 30 ],
29 "content": "Nostrasia travel expenses", 31 "content": "Nostrasia travel expenses",
30 ...other fields 32 ...
31``` 33```
32 34
33The following tags are OPTIONAL. 35The following tags are OPTIONAL.
@@ -43,7 +45,8 @@ The following tags are OPTIONAL.
43 ["closed_at", "<unix timestamp in seconds>"], 45 ["closed_at", "<unix timestamp in seconds>"],
44 ], 46 ],
45 "content": "Nostrasia travel expenses", 47 "content": "Nostrasia travel expenses",
46 ...other fields 48 ...
49}
47``` 50```
48 51
49The goal MAY include an `r` or `a` tag linking to a URL or parameterized replaceable event. 52The goal MAY include an `r` or `a` tag linking to a URL or parameterized replaceable event.
@@ -54,12 +57,14 @@ Parameterized replaceable events can link to a goal by using a `goal` tag specif
54 57
55```json 58```json
56{ 59{
57 "kind": 3XXXX, 60 ...
61 "kind": 3xxxx,
58 "tags": [ 62 "tags": [
59 ... 63 ...
60 ["goal", "<event id>", "<Relay URL (optional)>"], 64 ["goal", "<event id>", "<Relay URL (optional)>"],
61 ], 65 ],
62 ...other fields 66 ...
67}
63``` 68```
64 69
65## Client behavior 70## Client behavior
diff --git a/78.md b/78.md
index 10ff535..0f2fada 100644
--- a/78.md
+++ b/78.md
@@ -4,7 +4,7 @@ NIP-78
4Arbitrary custom app data 4Arbitrary custom app data
5------------------------- 5-------------------------
6 6
7`draft` `optional` `author:sandwich` `author:fiatjaf` 7`draft` `optional`
8 8
9The goal of this NIP is to enable [remoteStorage](https://remotestorage.io/)-like capabilities for custom applications that do not care about interoperability. 9The goal of this NIP is to enable [remoteStorage](https://remotestorage.io/)-like capabilities for custom applications that do not care about interoperability.
10 10
diff --git a/84.md b/84.md
index 4caab62..d5f54d4 100644
--- a/84.md
+++ b/84.md
@@ -4,7 +4,7 @@ NIP-84
4Highlights 4Highlights
5---------- 5----------
6 6
7`draft` `optional` `author:pablof7z` 7`draft` `optional`
8 8
9This NIP defines `kind:9802`, a "highlight" event, to signal content a user finds valuable. 9This NIP defines `kind:9802`, a "highlight" event, to signal content a user finds valuable.
10 10
@@ -27,11 +27,16 @@ useful when highlighting non-nostr content for which the client might be able to
27last value of the tag. 27last value of the tag.
28 28
29```json 29```json
30[ "p", "<pubkey-hex>", "<relay-url>", "author" ], 30{
31[ "p", "<pubkey-hex>", "<relay-url>", "author" ], 31 "tags": [
32[ "p", "<pubkey-hex>", "<relay-url>", "editor" ], 32 ["p", "<pubkey-hex>", "<relay-url>", "author"],
33 ["p", "<pubkey-hex>", "<relay-url>", "author"],
34 ["p", "<pubkey-hex>", "<relay-url>", "editor"]
35 ],
36 ...
37}
33``` 38```
34 39
35### Context 40### Context
36Clients MAY include a `context` tag, useful when the highlight is a subset of a paragraph and displaying the 41Clients MAY include a `context` tag, useful when the highlight is a subset of a paragraph and displaying the
37surrounding content might be beneficial to give context to the higlight. 42surrounding content might be beneficial to give context to the highlight.
diff --git a/89.md b/89.md
index 4503ecf..be3d075 100644
--- a/89.md
+++ b/89.md
@@ -4,15 +4,17 @@ NIP-89
4Recommended Application Handlers 4Recommended Application Handlers
5-------------------------------- 5--------------------------------
6 6
7`draft` `optional` `author:pablof7z` 7`draft` `optional`
8 8
9This NIP describes `kind:31989` and `kind:31990`: a way to discover applications that can handle unknown event-kinds. 9This NIP describes `kind:31989` and `kind:31990`: a way to discover applications that can handle unknown event-kinds.
10 10
11## Rationale 11## Rationale
12
12Nostr's discoverability and transparent event interaction is one of its most interesting/novel mechanics. 13Nostr's discoverability and transparent event interaction is one of its most interesting/novel mechanics.
13This NIP provides a simple way for clients to discover applications that handle events of a specific kind to ensure smooth cross-client and cross-kind interactions. 14This NIP provides a simple way for clients to discover applications that handle events of a specific kind to ensure smooth cross-client and cross-kind interactions.
14 15
15### Parties involved 16### Parties involved
17
16There are three actors to this workflow: 18There are three actors to this workflow:
17 19
18* application that handles a specific event kind (note that an application doesn't necessarily need to be a distinct entity and it could just be the same pubkey as user A) 20* application that handles a specific event kind (note that an application doesn't necessarily need to be a distinct entity and it could just be the same pubkey as user A)
@@ -22,18 +24,18 @@ There are three actors to this workflow:
22* user B, who seeks a recommendation for an app that handles a specific event kind 24* user B, who seeks a recommendation for an app that handles a specific event kind
23 * Queries for `kind:31989` and, based on results, queries for `kind:31990` 25 * Queries for `kind:31989` and, based on results, queries for `kind:31990`
24 26
25# Events 27## Events
26 28
27## Recommendation event 29### Recommendation event
28```json 30```json
29{ 31{
30 "kind": 31989, 32 "kind": 31989,
31 "pubkey": <recommender-user-pubkey>, 33 "pubkey": <recommender-user-pubkey>,
32 "tags": [ 34 "tags": [
33 [ "d", <supported-event-kind> ], 35 ["d", <supported-event-kind>],
34 [ "a", "31990:app1-pubkey:<d-identifier>", "wss://relay1", "ios" ], 36 ["a", "31990:app1-pubkey:<d-identifier>", "wss://relay1", "ios"],
35 [ "a", "31990:app2-pubkey:<d-identifier>", "wss://relay2", "web" ] 37 ["a", "31990:app2-pubkey:<d-identifier>", "wss://relay2", "web"]
36 ] 38 ]
37} 39}
38``` 40```
39 41
@@ -47,70 +49,83 @@ The third value of the tag SHOULD be the platform where this recommendation migh
47## Handler information 49## Handler information
48```json 50```json
49{ 51{
50 "kind": 31990, 52 "kind": 31990,
51 "pubkey": <pubkey>, 53 "pubkey": "<application-pubkey>",
52 "content": "<optional-kind:0-style-metadata>", 54 "content": "<optional-kind:0-style-metadata>",
53 "tags": [ 55 "tags": [
54 [ "d", <random-id> ], 56 ["d", <random-id>],
55 [ "k", <supported-event-kind> ], 57 ["k", <supported-event-kind>],
56 [ "web", "https://..../a/<bech32>", "nevent" ], 58 ["web", "https://..../a/<bech32>", "nevent"],
57 [ "web", "https://..../p/<bech32>", "nprofile" ], 59 ["web", "https://..../p/<bech32>", "nprofile"],
58 [ "web", "https://..../e/<bech32>" ], 60 ["web", "https://..../e/<bech32>"],
59 [ "ios", ".../<bech32>" ] 61 ["ios", ".../<bech32>"]
60 ] 62 ]
61} 63}
62``` 64```
63 65
64* `content` is an optional `metadata`-like stringified JSON object, as described in NIP-01. This content is useful when the pubkey creating the `kind:31990` is not an application. If `content` is empty, the `kind:0` of the pubkey should be used to display application information (e.g. name, picture, web, LUD16, etc.) 66* `content` is an optional `metadata`-like stringified JSON object, as described in NIP-01. This content is useful when the pubkey creating the `kind:31990` is not an application. If `content` is empty, the `kind:0` of the pubkey should be used to display application information (e.g. name, picture, web, LUD16, etc.)
65
66* `k` tags' value is the event kind that is supported by this `kind:31990`. 67* `k` tags' value is the event kind that is supported by this `kind:31990`.
67Using a `k` tag(s) (instead of having the kind onf the NIP-33 `d` tag) provides: 68Using a `k` tag(s) (instead of having the kind onf the NIP-33 `d` tag) provides:
68 * Multiple `k` tags can exist in the same event if the application supports more than one event kind and their handler URLs are the same. 69 * Multiple `k` tags can exist in the same event if the application supports more than one event kind and their handler URLs are the same.
69 * The same pubkey can have multiple events with different apps that handle the same event kind. 70 * The same pubkey can have multiple events with different apps that handle the same event kind.
70
71* `bech32` in a URL MUST be replaced by clients with the NIP-19-encoded entity that should be loaded by the application. 71* `bech32` in a URL MUST be replaced by clients with the NIP-19-encoded entity that should be loaded by the application.
72 72
73Multiple tags might be registered by the app, following NIP-19 nomenclature as the second value of the array. 73Multiple tags might be registered by the app, following NIP-19 nomenclature as the second value of the array.
74 74
75A tag without a second value in the array SHOULD be considered a generic handler for any NIP-19 entity that is not handled by a different tag. 75A tag without a second value in the array SHOULD be considered a generic handler for any NIP-19 entity that is not handled by a different tag.
76 76
77# User flow 77## Client tag
78When publishing events, clients MAY include a `client` tag in the same format as the recommendation event's `a` tags. This has privacy implications for users, so clients SHOULD allow users to opt-out of using this tag.
79
80```json
81{
82 "kind": 1,
83 "tags": [
84 ["client", "31990:app1-pubkey:<d-identifier>", "wss://relay1", "ios"]
85 ]
86 ...
87}
88```
89
90## User flow
78A user A who uses a non-`kind:1`-centric nostr app could choose to announce/recommend a certain kind-handler application. 91A user A who uses a non-`kind:1`-centric nostr app could choose to announce/recommend a certain kind-handler application.
79 92
80When user B sees an unknown event kind, e.g. in a social-media centric nostr client, the client would allow user B to interact with the unknown-kind event (e.g. tapping on it). 93When user B sees an unknown event kind, e.g. in a social-media centric nostr client, the client would allow user B to interact with the unknown-kind event (e.g. tapping on it).
81 94
82The client MIGHT query for the user's and the user's follows handler. 95The client MIGHT query for the user's and the user's follows handler.
83 96
84# Example 97## Example
85 98
86## User A recommends a `kind:31337`-handler 99### User A recommends a `kind:31337`-handler
87User A might be a user of Zapstr, a `kind:31337`-centric client (tracks). Using Zapstr, user A publishes an event recommending Zapstr as a `kind:31337`-handler. 100User A might be a user of Zapstr, a `kind:31337`-centric client (tracks). Using Zapstr, user A publishes an event recommending Zapstr as a `kind:31337`-handler.
88 101
89```json 102```json
90{ 103{
91 "kind": 31989, 104 "kind": 31989,
92 "tags": [ 105 "tags": [
93 [ "d", "31337" ], 106 ["d", "31337"],
94 [ "a", "31990:1743058db7078661b94aaf4286429d97ee5257d14a86d6bfa54cb0482b876fb0:abcd", <relay-url>, "web" ] 107 ["a", "31990:1743058db7078661b94aaf4286429d97ee5257d14a86d6bfa54cb0482b876fb0:abcd", <relay-url>, "web"]
95 ] 108 ],
109 ...
96} 110}
97``` 111```
98 112
99## User B interacts with a `kind:31337`-handler 113### User B interacts with a `kind:31337`-handler
100User B might see in their timeline an event referring to a `kind:31337` event 114User B might see in their timeline an event referring to a `kind:31337` event (e.g. a `kind:1` tagging a `kind:31337`).
101(e.g. a `kind:1` tagging a `kind:31337`).
102 115
103User B's client, not knowing how to handle a `kind:31337` might display the event 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`:
104using its `alt` tag (as described in NIP-31). When the user clicks on the event,
105the application queries for a handler for this `kind`:
106 117
107`["REQ", <id>, '[{ "kinds": [31989], "#d": ["31337"], 'authors': [<user>, <users-contact-list>] }]']` 118```json
119["REQ", <id>, '[{ "kinds": [31989], "#d": ["31337"], 'authors': [<user>, <users-contact-list>] }]']
120```
108 121
109User 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.
110 123
111User B's client sees the application's `kind:31990` which includes the information to redirect the user to the relevant URL with the desired entity replaced in the URL. 124User B's client sees the application's `kind:31990` which includes the information to redirect the user to the relevant URL with the desired entity replaced in the URL.
112 125
113## Alternative query bypassing `kind:31989` 126### Alternative query bypassing `kind:31989`
114Alternatively, users might choose to query directly for `kind:31990` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms 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.
115 128
116`["REQ", <id>, '[{ "kinds": [31990], "#k": [<desired-event-kind>], 'authors': [...] }]']` \ No newline at end of file 129```json
130["REQ", <id>, '[{ "kinds": [31990], "#k": [<desired-event-kind>], 'authors': [...] }]']
131```
diff --git a/90.md b/90.md
index 31447f2..6017c98 100644
--- a/90.md
+++ b/90.md
@@ -4,7 +4,7 @@ NIP-90
4Data Vending Machine 4Data Vending Machine
5-------------------- 5--------------------
6 6
7`draft` `optional` `author:pablof7z` `author:dontbelievethehype` 7`draft` `optional`
8 8
9This NIP defines the interaction between customers and Service Providers for performing on-demand computation. 9This NIP defines the interaction between customers and Service Providers for performing on-demand computation.
10 10
@@ -13,11 +13,11 @@ Money in, data out.
13## Kinds 13## Kinds
14This NIP reserves the range `5000-7000` for data vending machine use. 14This NIP reserves the range `5000-7000` for data vending machine use.
15 15
16| Kind | Description | 16| Kind | Description |
17| ---- | ----------- | 17| ---- | ----------- |
18| 5000-5999 | Job request kinds | 18| 5000-5999 | Job request kinds |
19| 6000-6999 | Job result | 19| 6000-6999 | Job result |
20| 7000 | Job feedback | 20| 7000 | Job feedback |
21 21
22Job results always use a kind number that is `1000` higher than the job request kind. (e.g. request: `kind:5001` gets a result: `kind:6001`). 22Job results always use a kind number that is `1000` higher than the job request kind. (e.g. request: `kind:5001` gets a result: `kind:6001`).
23 23
@@ -67,34 +67,34 @@ All tags are optional.
67* `relays`: List of relays where Service Providers SHOULD publish responses to 67* `relays`: List of relays where Service Providers SHOULD publish responses to
68* `p`: Service Providers the customer is interested in. Other SPs MIGHT still choose to process the job 68* `p`: Service Providers the customer is interested in. Other SPs MIGHT still choose to process the job
69 69
70## Encrypted Params 70## Encrypted Params
71 71
72If the user wants to keep the input parameters a secret, they can encrypt the `i` and `param` tags with the service provider's 'p' tag and add it to the content field. Add a tag `encrypted` as tags. Encryption for private tags will use [NIP-04 - Encrypted Direct Message encryption](https://github.com/nostr-protocol/nips/blob/master/04.md), using the user's private and service provider's public key for the shared secret 72If the user wants to keep the input parameters a secret, they can encrypt the `i` and `param` tags with the service provider's 'p' tag and add it to the content field. Add a tag `encrypted` as tags. Encryption for private tags will use [NIP-04 - Encrypted Direct Message encryption](https://github.com/nostr-protocol/nips/blob/master/04.md), using the user's private and service provider's public key for the shared secret
73 73
74```json 74```json
75[ 75[
76 [ "i", "what is the capital of France? ", "text" ], 76 ["i", "what is the capital of France? ", "text"],
77 [ "param", "model", "LLaMA-2" ], 77 ["param", "model", "LLaMA-2"],
78 [ "param", "max_tokens", "512" ], 78 ["param", "max_tokens", "512"],
79 [ "param", "temperature", "0.5" ], 79 ["param", "temperature", "0.5"],
80 [ "param", "top-k", "50" ], 80 ["param", "top-k", "50"],
81 [ "param", "top-p", "0.7" ], 81 ["param", "top-p", "0.7"],
82 [ "param", "frequency_penalty", "1" ] 82 ["param", "frequency_penalty", "1"]
83
84] 83]
85 84
86``` 85```
87 86
88This param data will be encrypted and added to the `content` field and `p` tag should be present 87This param data will be encrypted and added to the `content` field and `p` tag should be present
89
90```
91"content": "BE2Y4xvS6HIY7TozIgbEl3sAHkdZoXyLRRkZv4fLPh3R7LtviLKAJM5qpkC7D6VtMbgIt4iNcMpLtpo...",
92 "tags": [
93 ["p", "04f74530a6ede6b24731b976b8e78fb449ea61f40ff10e3d869a3030c4edc91f"],
94 ["encrypted"]
95 ]
96
97 88
89```json
90{
91 "content": "BE2Y4xvS6HIY7TozIgbEl3sAHkdZoXyLRRkZv4fLPh3R7LtviLKAJM5qpkC7D6VtMbgIt4iNcMpLtpo...",
92 "tags": [
93 ["p", "04f74530a6ede6b24731b976b8e78fb449ea61f40ff10e3d869a3030c4edc91f"],
94 ["encrypted"]
95 ],
96 ...
97}
98``` 98```
99 99
100 100
@@ -104,16 +104,17 @@ Service providers publish job results, providing the output of the job result. T
104 104
105```json 105```json
106{ 106{
107 "pubkey": "<service-provider pubkey>", 107 "pubkey": "<service-provider pubkey>",
108 "content": "<payload>", 108 "content": "<payload>",
109 "kind": 6xxx, 109 "kind": 6xxx,
110 "tags": [ 110 "tags": [
111 [ "request", "<job-request>" ], 111 ["request", "<job-request>"],
112 [ "e", "<job-request-id>", "<relay-hint>" ], 112 ["e", "<job-request-id>", "<relay-hint>"],
113 [ "i", "<input-data>" ], 113 ["i", "<input-data>"],
114 [ "p", "<customer's-pubkey>" ], 114 ["p", "<customer's-pubkey>"],
115 [ "amount", "requested-payment-amount", "<optional-bolt11>" ] 115 ["amount", "requested-payment-amount", "<optional-bolt11>"]
116 ] 116 ],
117 ...
117} 118}
118``` 119```
119 120
@@ -123,38 +124,40 @@ Service providers publish job results, providing the output of the job result. T
123 124
124## Encrypted Output 125## Encrypted Output
125 126
126If the request has encrypted params, then output should be encrypted and placed in `content` field. If the output is encrypted, then avoid including `i` tag with input-data as clear text. 127If the request has encrypted params, then output should be encrypted and placed in `content` field. If the output is encrypted, then avoid including `i` tag with input-data as clear text.
127Add a tag encrypted to mark the output content as `encrypted` 128Add a tag encrypted to mark the output content as `encrypted`
129
128```json 130```json
129{ 131{
130 "pubkey": "<service-provider pubkey>", 132 "pubkey": "<service-provider pubkey>",
131 "content": "<encrypted payload>", 133 "content": "<encrypted payload>",
132 "kind": 6xxx, 134 "kind": 6xxx,
133 "tags": [ 135 "tags": [
134 [ "request", "<job-request>" ], 136 ["request", "<job-request>"],
135 [ "e", "<job-request-id>", "<relay-hint>" ], 137 ["e", "<job-request-id>", "<relay-hint>"],
136 [ "p", "<customer's-pubkey>" ], 138 ["p", "<customer's-pubkey>"],
137 [ "amount", "requested-payment-amount", "<optional-bolt11>" ], 139 ["amount", "requested-payment-amount", "<optional-bolt11>"],
138 ["encrypted"] 140 ["encrypted"]
139 141 ],
140 ] 142 ...
141} 143}
142``` 144```
143
144 145
145## Job feedback 146## Job feedback
147
146Service providers can give feedback about a job back to the customer. 148Service providers can give feedback about a job back to the customer.
147 149
148```json 150```json
149{ 151{
150 "kind": 7000, 152 "kind": 7000,
151 "content": "<empty-or-payload>", 153 "content": "<empty-or-payload>",
152 "tags": [ 154 "tags": [
153 [ "status", "<status>", "<extra-info>" ], 155 ["status", "<status>", "<extra-info>"],
154 [ "amount", "requested-payment-amount", "<bolt11>" ], 156 ["amount", "requested-payment-amount", "<bolt11>"],
155 [ "e", "<job-request-id>", "<relay-hint>" ], 157 ["e", "<job-request-id>", "<relay-hint>"],
156 [ "p", "<customer's-pubkey>" ], 158 ["p", "<customer's-pubkey>"],
157 ] 159 ],
160 ...
158} 161}
159``` 162```
160 163
@@ -162,22 +165,23 @@ Service providers can give feedback about a job back to the customer.
162* `amount` tag: as defined in the [Job Result](#job-result) section. 165* `amount` tag: as defined in the [Job Result](#job-result) section.
163* `status` tag: Service Providers SHOULD indicate what this feedback status refers to. [Appendix 1](#appendix-1-job-feedback-status) defines status. Extra human-readable information can be added as an extra argument. 166* `status` tag: Service Providers SHOULD indicate what this feedback status refers to. [Appendix 1](#appendix-1-job-feedback-status) defines status. Extra human-readable information can be added as an extra argument.
164 167
165* NOTE: If the input params requires input to be encryped, then `content` field will have encrypted payload with `p` tag as key. 168* NOTE: If the input params requires input to be encrypted, then `content` field will have encrypted payload with `p` tag as key.
166 169
167### Job feedback status 170### Job feedback status
168 171
169| status | description | 172| status | description |
170|--------|-------------| 173| -------- | ------------- |
171| `payment-required` | Service Provider requires payment before continuing. | 174| `payment-required` | Service Provider requires payment before continuing. |
172| `processing` | Service Provider is processing the job. | 175| `processing` | Service Provider is processing the job. |
173| `error` | Service Provider was unable to process the job. | 176| `error` | Service Provider was unable to process the job. |
174| `success` | Service Provider successfully processed the job. | 177| `success` | Service Provider successfully processed the job. |
175| `partial` | Service Provider partially processed the job. The `.content` might include a sample of the partial results. | 178| `partial` | Service Provider partially processed the job. The `.content` might include a sample of the partial results. |
176 179
177Any job feedback event MIGHT include results in the `.content` field, as described in the [Job Result](#job-result) section. This is useful for service providers to provide a sample of the results that have been processed so far. 180Any job feedback event MIGHT include results in the `.content` field, as described in the [Job Result](#job-result) section. This is useful for service providers to provide a sample of the results that have been processed so far.
178 181
179 182
180# Protocol Flow 183# Protocol Flow
184
181* Customer publishes a job request (e.g. `kind:5000` speech-to-text). 185* Customer publishes a job request (e.g. `kind:5000` speech-to-text).
182* Service Providers MAY submit `kind:7000` job-feedback events (e.g. `payment-required`, `processing`, `error`, etc.). 186* Service Providers MAY submit `kind:7000` job-feedback events (e.g. `payment-required`, `processing`, `error`, etc.).
183* Upon completion, the service provider publishes the result of the job with a `kind:6000` job-result event. 187* Upon completion, the service provider publishes the result of the job with a `kind:6000` job-result event.
@@ -207,18 +211,19 @@ This gives a higher level of flexibility to service providers (which sophisticat
207# Appendix 2: Service provider discoverability 211# Appendix 2: Service provider discoverability
208Service Providers MAY use NIP-89 announcements to advertise their support for job kinds: 212Service Providers MAY use NIP-89 announcements to advertise their support for job kinds:
209 213
210```json 214```js
211{ 215{
212 "kind": 31990, 216 "kind": 31990,
213 "pubkey": "<pubkey>", 217 "pubkey": "<pubkey>",
214 "content": "{ 218 "content": "{
215 \"name\": \"Translating DVM\", 219 \"name\": \"Translating DVM\",
216 \"about\": \"I'm a DVM specialized in translating Bitcoin content.\" 220 \"about\": \"I'm a DVM specialized in translating Bitcoin content.\"
217 }", 221 }",
218 "tags": [ 222 "tags": [
219 [ "k", "5005" ], // e.g. translation 223 ["k", "5005"], // e.g. translation
220 [ "t", "bitcoin" ] // e.g. optionally advertises it specializes in bitcoin audio transcription that won't confuse "Drivechains" with "Ridechains" 224 ["t", "bitcoin"] // e.g. optionally advertises it specializes in bitcoin audio transcription that won't confuse "Drivechains" with "Ridechains"
221 ] 225 ],
226 ...
222} 227}
223``` 228```
224 229
diff --git a/94.md b/94.md
index c5e0f18..95b6a3b 100644
--- a/94.md
+++ b/94.md
@@ -4,7 +4,7 @@ NIP-94
4File Metadata 4File Metadata
5------------- 5-------------
6 6
7`draft` `optional` `author:frbitten` `author:kieran` `author:lovvtide` `author:fiatjaf` `author:staab` 7`draft` `optional`
8 8
9The purpose of this NIP is to allow an organization and classification of shared files. So that relays can filter and organize in any way that is of interest. With that, multiple types of filesharing clients can be created. NIP-94 support is not expected to be implemented by "social" clients that deal with kind:1 notes or by longform clients that deal with kind:30023 articles. 9The purpose of this NIP is to allow an organization and classification of shared files. So that relays can filter and organize in any way that is of interest. With that, multiple types of filesharing clients can be created. NIP-94 support is not expected to be implemented by "social" clients that deal with kind:1 notes or by longform clients that deal with kind:30023 articles.
10 10
@@ -28,9 +28,6 @@ This NIP specifies the use of the `1063` event type, having in `content` a descr
28 28
29```json 29```json
30{ 30{
31 "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>,
32 "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
33 "created_at": <unix timestamp in seconds>,
34 "kind": 1063, 31 "kind": 1063,
35 "tags": [ 32 "tags": [
36 ["url",<string with URI of file>], 33 ["url",<string with URI of file>],
@@ -47,8 +44,8 @@ This NIP specifies the use of the `1063` event type, having in `content` a descr
47 ["summary", <excerpt>], 44 ["summary", <excerpt>],
48 ["alt", <description>] 45 ["alt", <description>]
49 ], 46 ],
50 "content": <caption>, 47 "content": "<caption>",
51 "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field> 48 ...
52} 49}
53``` 50```
54 51
diff --git a/98.md b/98.md
index c8cba0f..ca52304 100644
--- a/98.md
+++ b/98.md
@@ -2,9 +2,9 @@ NIP-98
2====== 2======
3 3
4HTTP Auth 4HTTP Auth
5------------------------- 5---------
6 6
7`draft` `optional` `author:kieran` `author:melvincarvalho` 7`draft` `optional`
8 8
9This NIP defines an ephemeral event used to authorize requests to HTTP servers using nostr events. 9This NIP defines an ephemeral event used to authorize requests to HTTP servers using nostr events.
10 10
@@ -24,22 +24,16 @@ The following tags MUST be included.
24Example event: 24Example event:
25```json 25```json
26{ 26{
27 "id": "fe964e758903360f28d8424d092da8494ed207cba823110be3a57dfe4b578734", 27 "id": "fe964e758903360f28d8424d092da8494ed207cba823110be3a57dfe4b578734",
28 "pubkey": "63fe6318dc58583cfe16810f86dd09e18bfd76aabc24a0081ce2856f330504ed", 28 "pubkey": "63fe6318dc58583cfe16810f86dd09e18bfd76aabc24a0081ce2856f330504ed",
29 "content": "", 29 "content": "",
30 "kind": 27235, 30 "kind": 27235,
31 "created_at": 1682327852, 31 "created_at": 1682327852,
32 "tags": [ 32 "tags": [
33 [ 33 ["u", "https://api.snort.social/api/v1/n5sp/list"],
34 "u", 34 ["method", "GET"]
35 "https://api.snort.social/api/v1/n5sp/list" 35 ],
36 ], 36 "sig": "5ed9d8ec958bc854f997bdc24ac337d005af372324747efe4a00e24f4c30437ff4dd8308684bed467d9d6be3e5a517bb43b1732cc7d33949a3aaf86705c22184"
37 [
38 "method",
39 "GET"
40 ]
41 ],
42 "sig": "5ed9d8ec958bc854f997bdc24ac337d005af372324747efe4a00e24f4c30437ff4dd8308684bed467d9d6be3e5a517bb43b1732cc7d33949a3aaf86705c22184"
43} 37}
44``` 38```
45 39
diff --git a/99.md b/99.md
index 274e5af..e65920c 100644
--- a/99.md
+++ b/99.md
@@ -1,8 +1,10 @@
1# NIP-99 1NIP-99
2======
2 3
3## Classified Listings 4Classified Listings
5-------------------
4 6
5`draft` `optional` `author:erskingardner` 7`draft` `optional`
6 8
7This 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.
8 10
diff --git a/README.md b/README.md
index 790f0b6..b8b98d9 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,7 @@
1# NIPs 1# NIPs
2 2
3NIPs stand for **Nostr Implementation Possibilities**. 3NIPs stand for **Nostr Implementation Possibilities**.
4
4They exist to document what may be implemented by [Nostr](https://github.com/nostr-protocol/nostr)-compatible _relay_ and _client_ software. 5They exist to document what may be implemented by [Nostr](https://github.com/nostr-protocol/nostr)-compatible _relay_ and _client_ software.
5 6
6--- 7---
@@ -12,7 +13,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
12 - [Relay to Client](#relay-to-client) 13 - [Relay to Client](#relay-to-client)
13- [Standardized Tags](#standardized-tags) 14- [Standardized Tags](#standardized-tags)
14- [Criteria for acceptance of NIPs](#criteria-for-acceptance-of-nips) 15- [Criteria for acceptance of NIPs](#criteria-for-acceptance-of-nips)
15- [Mailing Lists](#mailing-lists) 16- [Is this repository a centralizing factor?](#is-this-repository-a-centralizing-factor)
17- [How this repository works](#how-this-repository-works)
16- [License](#license) 18- [License](#license)
17 19
18--- 20---
@@ -226,21 +228,26 @@ Please update these lists when proposing NIPs introducing new event kinds.
2264. There should be no more than one way of doing the same thing. 2284. There should be no more than one way of doing the same thing.
2275. Other rules will be made up when necessary. 2295. Other rules will be made up when necessary.
228 230
229## Mailing Lists 231## Is this repository a centralizing factor?
232
233To promote interoperability, we standards that everybody can follow, and we need them to define a **single way of doing each thing** without ever hurting **backwards-compatibility**, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such index exists doesn't hurt the decentralization of Nostr. _At any point the central index can be challenged if it is failing to fulfill the needs of the protocol_ and it can migrate to other places and be maintained by other people.
234
235It can even fork into multiple and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.
230 236
231The nostr ecosystem is getting large with many different organizations, relays 237There is a list of notable Nostr software developers who have commit access to this repository, but that exists mostly for practical reasons, as by the nature of the thing we're dealing with the repository owner can revoke membership and rewrite history as they want -- and if these actions are unjustified or perceived as bad or evil the community must react.
232and clients. Following the nips repo on github is becoming more difficult and
233noisy. To coordinate on protocol development outside of github, there are
234mailing lists where you can work on NIPs before submitting them here:
235 238
236* [w3c nostr community group][w3-nostr] - [public-nostr@w3.org][mailto-w3] - requires signup 239## How this repository works
237* [nostr-protocol google group][nostr-google-group] - [nostr-protocol@googlegroups.com][mailto-google] - no signup required
238 240
239[w3-nostr]: https://www.w3.org/community/nostr/ 241Standards may emerge in two ways: the first way is that someone starts doing something, then others copy it; the second way is that someone has an idea of a new standard that could benefit multiple clients and the protocol in general without breaking **backwards-compatibility** and the principle of having **a single way of doing things**, then they write that idea and submit it to this repository, other interested parties read it and give their feedback, then once most people reasonably agree we codify that in a NIP which client and relay developers that are interested in the feature can proceed to implement.
240[mailto-w3]: mailto:public-nostr@w3.org 242
241[nostr-google-group]: https://groups.google.com/g/nostr-protocol 243These two ways of standardizing things are supported by this repository. Although the second is preferred, an effort will be made to codify standards emerged outside this repository into NIPs that can be later referenced and easily understood and implemented by others -- but obviously as in any human system discretion may be applied when standards are considered harmful.
242[mailto-google]: mailto:nostr-protocol@googlegroups.com
243 244
244## License 245## License
245 246
246All NIPs are public domain. 247All NIPs are public domain.
248
249## Contributors
250
251<a align="center" href="https://github.com/nostr-protocol/nips/graphs/contributors">
252 <img src="https://contrib.rocks/image?repo=nostr-protocol/nips" />
253</a>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-09 21:04:22 +0000