upleb.uk

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

summaryrefslogtreecommitdiff
path: root/15.md
diff options
context:
space:
mode:
Diffstat (limited to '15.md')
-rw-r--r--15.md293
1 files changed, 189 insertions, 104 deletions
diff --git a/15.md b/15.md
index 68d28ff..55814fb 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,39 +71,44 @@ 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
104Fields that are not self-explanatory: 110Fields that are not self-explanatory:
105 - `quantity` can be null in the case of items with unlimited abailability, like digital items, or services 111 - `quantity` can be null in the case of items with unlimited availability, like digital items, or services
106 - `specs`: 112 - `specs`:
107 - an optional array of key pair values. It allows for the Customer UI to present product specifications in a structure mode. It also allows comparison between products 113 - an optional array of key pair values. It allows for the Customer UI to present product specifications in a structure mode. It also allows comparison between products
108 - eg: `[["operating_system", "Android 12.0"], ["screen_size", "6.4 inches"], ["connector_type", "USB Type C"]]` 114 - eg: `[["operating_system", "Android 12.0"], ["screen_size", "6.4 inches"], ["connector_type", "USB Type C"]]`
@@ -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`.
@@ -131,7 +139,7 @@ Fields that are not self-explanatory:
131 139
132## Checkout events 140## Checkout events
133 141
134All checkout events are sent as JSON strings using ([NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md)). 142All checkout events are sent as JSON strings using ([NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md)).
135 143
136The `merchant` and the `customer` can exchange JSON messages that represent different actions. Each `JSON` message `MUST` have a `type` field indicating the what the JSON represents. Possible types: 144The `merchant` and the `customer` can exchange JSON messages that represent different actions. Each `JSON` message `MUST` have a `type` field indicating the what the JSON represents. Possible types:
137 145
@@ -141,29 +149,28 @@ The `merchant` and the `customer` can exchange JSON messages that represent diff
141| 1 | Merchant | Payment Request | 149| 1 | Merchant | Payment Request |
142| 2 | Merchant | Order Status Update | 150| 2 | Merchant | Order Status Update |
143 151
144
145### Step 1: `customer` order (event) 152### Step 1: `customer` order (event)
146The below json goes in content of [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md). 153The below JSON goes in content of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md).
147 154
148```json 155```json
149{ 156{
150 "id": <String, UUID generated by the customer>, 157 "id": <string, id generated by the customer>,
151 "type": 0, 158 "type": 0,
152 "name": <String (optional), ???>, 159 "name": <string (optional), ???>,
153 "address": <String (optional), for physical goods an address should be provided> 160 "address": <string (optional), for physical goods an address should be provided>,
154 "message": "<String (optional), message for merchant>, 161 "message": "<string (optional), message for merchant>,
155 "contact": { 162 "contact": {
156 "nostr": <32-bytes hex of a pubkey>, 163 "nostr": <32-bytes hex of a pubkey>,
157 "phone": <String (optional), if the customer wants to be contacted by phone>, 164 "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>, 165 "email": <string (optional), if the customer wants to be contacted by email>
159 }, 166 },
160 "items": [ 167 "items": [
161 { 168 {
162 "product_id": <String, UUID of the product>, 169 "product_id": <string, id of the product>,
163 "quantity": <int, how many products the customer is ordering> 170 "quantity": <int, how many products the customer is ordering>
164 } 171 }
165 ], 172 ],
166 "shipping_id": <String, UUID of the shipping zone> 173 "shipping_id": <string, id of the shipping zone>
167} 174}
168 175
169``` 176```
@@ -175,7 +182,7 @@ _Open_: is `contact.nostr` required?
175 182
176Sent back from the merchant for payment. Any payment option is valid that the merchant can check. 183Sent back from the merchant for payment. Any payment option is valid that the merchant can check.
177 184
178The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md). 185The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md).
179 186
180`payment_options`/`type` include: 187`payment_options`/`type` include:
181 188
@@ -186,23 +193,23 @@ The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/ni
186 193
187```json 194```json
188{ 195{
189 "id": <String, UUID of the order>, 196 "id": <string, id of the order>,
190 "type": 1, 197 "type": 1,
191 "message": <String, message to customer, optional>, 198 "message": <string, message to customer, optional>,
192 "payment_options": [ 199 "payment_options": [
193 { 200 {
194 "type": <String, option type>, 201 "type": <string, option type>,
195 "link": <String, url, btc address, ln invoice, etc> 202 "link": <string, url, btc address, ln invoice, etc>
196 }, 203 },
197 { 204 {
198 "type": <String, option type>, 205 "type": <string, option type>,
199 "link": <String, url, btc address, ln invoice, etc> 206 "link": <string, url, btc address, ln invoice, etc>
200 }, 207 },
201 { 208 {
202 "type": <String, option type>, 209 "type": <string, option type>,
203 "link": <String, url, btc address, ln invoice, etc> 210 "link": <string, url, btc address, ln invoice, etc>
204 } 211 }
205 ] 212 ]
206} 213}
207``` 214```
208 215
@@ -210,40 +217,118 @@ The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/ni
210 217
211Once payment has been received and processed. 218Once payment has been received and processed.
212 219
213The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md). 220The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md).
214 221
215```json 222```json
216{ 223{
217 "id": <String, UUID of the order>, 224 "id": <string, id of the order>,
218 "type": 2, 225 "type": 2,
219 "message": <String, message to customer>, 226 "message": <string, message to customer>,
220 "paid": <Bool, true/false has received payment>, 227 "paid": <bool: has received payment>,
221 "shipped": <Bool, true/false has been shipped>, 228 "shipped": <bool: has been shipped>,
222} 229}
223``` 230```
231
224## Customize Marketplace 232## Customize Marketplace
233
225Create a customized user experience using the `naddr` from [NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md#shareable-identifiers-with-extra-metadata). The use of `naddr` enables easy sharing of marketplace events while incorporating a rich set of metadata. This metadata can include relays, merchant profiles, and more. Subsequently, it allows merchants to be grouped into a market, empowering the market creator to configure the marketplace's user interface and user experience, and share that marketplace. This customization can encompass elements such as market name, description, logo, banner, themes, and even color schemes, offering a tailored and unique marketplace experience. 234Create a customized user experience using the `naddr` from [NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md#shareable-identifiers-with-extra-metadata). The use of `naddr` enables easy sharing of marketplace events while incorporating a rich set of metadata. This metadata can include relays, merchant profiles, and more. Subsequently, it allows merchants to be grouped into a market, empowering the market creator to configure the marketplace's user interface and user experience, and share that marketplace. This customization can encompass elements such as market name, description, logo, banner, themes, and even color schemes, offering a tailored and unique marketplace experience.
226 235
227### Event `30019`: Create or update marketplace UI/UX 236### Event `30019`: Create or update marketplace UI/UX
228 237
229**Event Content**: 238**Event Content**
239
230```json 240```json
231{ 241{
232 "name": <String (optional), market name>, 242 "name": <string (optional), market name>,
233 "about": <String (optional), market description>, 243 "about": <string (optional), market description>,
234 "ui": { 244 "ui": {
235 "picture": <String (optional), market logo image URL>, 245 "picture": <string (optional), market logo image URL>,
236 "banner": <String (optional), market logo banner URL>, 246 "banner": <string (optional), market logo banner URL>,
237 "theme": <String (optional), market theme>, 247 "theme": <string (optional), market theme>,
238 "darkMode": <Bool, true/false> 248 "darkMode": <bool, true/false>
239 }, 249 },
240 "merchants": <[String] (optional), array of pubkeys>, 250 "merchants": [array of pubkeys (optional)],
241 ... 251 ...
242} 252}
243``` 253```
244 254
245This event leverages naddr to enable comprehensive customization and sharing of marketplace configurations, fostering a unique and engaging marketplace environment. 255This event leverages naddr to enable comprehensive customization and sharing of marketplace configurations, fostering a unique and engaging marketplace environment.
246 256
257## Auctions
258
259### Event `30020`: Create or update a product sold as an auction
260
261**Event Content**:
262```json
263{
264 "id": <String, UUID generated by the merchant. Sequential IDs (`0`, `1`, `2`...) are discouraged>,
265 "stall_id": <String, UUID of the stall to which this product belong to>,
266 "name": <String, product name>,
267 "description": <String (optional), product description>,
268 "images": <[String], array of image URLs, optional>,
269 "starting_bid": <int>,
270 "start_date": <int (optional) UNIX timestamp, date the auction started / will start>,
271 "duration": <int, number of seconds the auction will run for, excluding eventual time extensions that might happen>,
272 "specs": [
273 [<String, spec key>, <String, spec value>]
274 ],
275 "shipping": [
276 {
277 "id": <String, UUID of the shipping zone. Must match one of the zones defined for the stall>,
278 "cost": <float, extra cost for shipping. The currency is defined at the stall level>
279 }
280 ]
281}
282```
283
284> [!NOTE]
285> Items sold as an auction are very similar in structure to fixed-price items, with some important differences worth noting.
286
287* The `start_date` can be set to a date in the future if the auction is scheduled to start on that date, or can be omitted if the start date is unknown/hidden. If the start date is not specified, the auction will have to be edited later to set an actual date.
288
289* The auction runs for an initial number of seconds after the `start_date`, specified by `duration`.
290
291### Event `1021`: Bid
292
293```json
294{
295 "content": <int, amount of sats>,
296 "tags": [["e", <event ID of the auction to bid on>]],
297}
298```
299
300Bids are simply events of kind `1021` with a `content` field specifying the amount, in the currency of the auction. Bids must reference an auction.
301
302> [!NOTE]
303> Auctions can be edited as many times as desired (they are "parameterized replaceable events") by the author - even after the start_date, but they cannot be edited after they have received the first bid! This is enforced by the fact that bids reference the event ID of the auction (rather than the product UUID), which changes with every new version of the auctioned product. So a bid is always attached to one "version". Editing the auction after a bid would result in the new product losing the bid!
304
305### Event `1022`: Bid confirmation
306
307**Event Content**:
308
309```json
310{
311 "status": <String, "accepted" | "rejected" | "pending" | "winner">,
312 "message": <String (optional)>,
313 "duration_extended": <int (optional), number of seconds>
314}
315```
316
317**Event Tags**:
318```json
319 "tags": [["e" <event ID of the bid being confirmed>], ["e", <event ID of the auction>]],
320```
321
322Bids should be confirmed by the merchant before being considered as valid by other clients. So clients should subscribe to *bid confirmation* events (kind `1022`) for every auction that they follow, in addition to the actual bids and should check that the pubkey of the bid confirmation matches the pubkey of the merchant (in addition to checking the signature).
323
324The `content` field is a JSON which includes *at least* a `status`. `winner` is how the *winning bid* is replied to after the auction ends and the winning bid is picked by the merchant.
325
326The reasons for which a bid can be marked as `rejected` or `pending` are up to the merchant's implementation and configuration - they could be anything from basic validation errors (amount too low) to the bidder being blacklisted or to the bidder lacking sufficient *trust*, which could lead to the bid being marked as `pending` until sufficient verification is performed. The difference between the two is that `pending` bids *might* get approved after additional steps are taken by the bidder, whereas `rejected` bids can not be later approved.
327
328An additional `message` field can appear in the `content` JSON to give further context as of why a bid is `rejected` or `pending`.
329
330Another thing that can happen is - if bids happen very close to the end date of the auction - for the merchant to decide to extend the auction duration for a few more minutes. This is done by passing a `duration_extended` field as part of a bid confirmation, which would contain a number of seconds by which the initial duration is extended. So the actual end date of an auction is always `start_date + duration + (SUM(c.duration_extended) FOR c in all confirmations`.
331
247## Customer support events 332## Customer support events
248 333
249Customer support is handled over whatever communication method was specified. If communicating via nostr, NIP-04 is used https://github.com/nostr-protocol/nips/blob/master/04.md. 334Customer support is handled over whatever communication method was specified. If communicating via nostr, NIP-04 is used https://github.com/nostr-protocol/nips/blob/master/04.md.
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-22 19:59:56 +0000