From fb5b7c739ff92cec4962990aa99c54fac9f5de81 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sun, 9 Apr 2023 08:50:24 -0300 Subject: merge NIP-15 into NIP-01. --- 15.md | 21 --------------------- 1 file changed, 21 deletions(-) delete mode 100644 15.md (limited to '15.md') diff --git a/15.md b/15.md deleted file mode 100644 index 081a97d..0000000 --- a/15.md +++ /dev/null @@ -1,21 +0,0 @@ -NIP-15 -====== - -End of Stored Events Notice ---------------------------- - -`final` `optional` `author:Semisol` - -Relays may support notifying clients when all stored events have been sent. - -If a relay supports this NIP, the relay SHOULD send the client a `EOSE` message in the format `["EOSE", ]` after it has sent all the events it has persisted and it indicates all the events that come after this message are newly published. - -Client Behavior ---------------- - -Clients SHOULD use the `supported_nips` field to learn if a relay supports end of stored events notices. - -Motivation ----------- - -The motivation for this proposal is to reduce uncertainty when all events have been sent by a relay to make client code possibly less complex. -- cgit v1.2.3 From bf0a0da6a48b96467172414d8e41dc72b0ca379c Mon Sep 17 00:00:00 2001 From: Arc <33088785+arcbtc@users.noreply.github.com> Date: Thu, 13 Apr 2023 11:13:04 +0100 Subject: NIP-15 Nostr marketplace (#330) Co-authored-by: Andrew Camilleri Co-authored-by: Vlad Stan --- 15.md | 214 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 214 insertions(+) create mode 100644 15.md (limited to '15.md') diff --git a/15.md b/15.md new file mode 100644 index 0000000..a3d105d --- /dev/null +++ b/15.md @@ -0,0 +1,214 @@ +NIP-15 +====== + +Nostr Marketplace (for resilient marketplaces) +----------------------------------- + +`draft` `optional` `author:fiatjaf` `author:benarc` `author:motorina0` `author:talvasconcelos` + +> Based on https://github.com/lnbits/Diagon-Alley + +> Implemented here https://github.com/lnbits/nostrmarket + +## Terms + +- `merchant` - seller of products with NOSTR key-pair +- `customer` - buyer of products with NOSTR key-pair +- `product` - item for sale by the `merchant` +- `stall` - list of products controlled by `merchant` (a `merchant` can have multiple stalls) +- `marketplace` - clientside software for searching `stalls` and purchasing `products` + +## Nostr Marketplace Clients + +### Merchant admin + +Where the `merchant` creates, updates and deletes `stalls` and `products`, as well as where they manage sales, payments and communication with `customers`. + +The `merchant` admin software can be purely clientside, but for `convenience` and uptime, implementations will likely have a server client listening for NOSTR events. + +### Marketplace + +`Marketplace` software should be entirely clientside, either as a stand-alone app, or as a purely frontend webpage. A `customer` subscribes to different merchant NOSTR public keys, and those `merchants` `stalls` and `products` become listed and searchable. The marketplace client is like any other ecommerce site, with basket and checkout. `Marketplaces` may also wish to include a `customer` support area for direct message communication with `merchants`. + +## `Merchant` publishing/updating products (event) + +A merchant can publish these events: +| Kind | | Description | NIP | +|---------|------------------|---------------------------------------------------------------------------------------------------------------|-----------------------------------------| +| `0 ` | `set_meta` | The merchant description (similar with any `nostr` public key). | [NIP01 ](https://github.com/nostr-protocol/nips/blob/master/01.md) | +| `30017` | `set_stall` | Create or update a stall. | [NIP33](https://github.com/nostr-protocol/nips/blob/master/33.md) (Parameterized Replaceable Event) | +| `30018` | `set_product` | Create or update a product. | [NIP33](https://github.com/nostr-protocol/nips/blob/master/33.md) (Parameterized Replaceable Event) | +| `4 ` | `direct_message` | Communicate with the customer. The messages can be plain-text or JSON. | [NIP09](https://github.com/nostr-protocol/nips/blob/master/09.md) | +| `5 ` | `delete` | Delete a product or a stall. | [NIP05](https://github.com/nostr-protocol/nips/blob/master/05.md) | + +### Event `30017`: Create or update a stall. + +**Event Content**: +```json +{ + "id": , + "name": , + "description": , + "currency": , + "shipping": [ + { + "id": , + "name": , + "cost": , + "countries": [], + } + ] +} +``` + +Fields that are not self-explanatory: + - `shipping`: + - an array with possible shipping zones for this stall. The customer MUST choose exactly one shipping zone. + - shipping to different zones can have different costs. For some goods (digital for examle) the cost can be zero. + - the `id` is an internal value used by the merchant. This value must be sent back as the customer selection. + +**Event Tags**: +```json + "tags": [["d", , + "stall_id": , + "name": , + "description": , + "images": <[String], array of image URLs, optional>, + "currency": , + "price": , + "quantity": , + "specs": [ + [ , ] + ] +} +``` + +Fields that are not self-explanatory: + - `specs`: + - an array of key pair values. It allows for the Customer UI to present present product specifications in a structure mode. It also allows comparison between products + - eg: `[["operating_system", "Android 12.0"], ["screen_size", "6.4 inches"], ["connector_type", "USB Type C"]]` + +_Open_: better to move `spec` in the `tags` section of the event? + +**Event Tags**: +```json + "tags": [ + ["d", , + "type": 0, + "name": , + "address": + "message": ", + "contact": { + "nostr": <32-bytes hex of a pubkey>, + "phone": , + "email": , + }, + "items": [ + { + "product_id": , + "quantity": + } + ], + "shipping_id": +} + +``` + +_Open_: is `contact.nostr` required? + + +### Step 2: `merchant` request payment (event) + +Sent back from the merchant for payment. Any payment option is valid that the merchant can check. + +The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md). + +`payment_options`/`type` include: + +- `url` URL to a payment page, stripe, paypal, btcpayserver, etc +- `btc` onchain bitcoin address +- `ln` bitcoin lightning invoice +- `lnurl` bitcoin lnurl-pay + +```json +{ + "id": , + "type": 1, + "message": , + "payment_options": [ + { + "type": , + "link": + }, + { + "type": , + "link": + }, + { + "type": , + "link": + } + ] +} +``` + +### Step 3: `merchant` verify payment/shipped (event) + +Once payment has been received and processed. + +The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md). + +```json +{ + "id": , + "type": 2, + "message": , + "paid": , + "shipped": , +} +``` + +## Customer support events + +Customer 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. + +## Additional + +Standard data models can be found here here -- cgit v1.2.3 From ebf94668dbafe7fd2f52a77aabbd1f35bdf86bb6 Mon Sep 17 00:00:00 2001 From: Luis Miguel Date: Fri, 14 Apr 2023 10:47:36 +0200 Subject: nip-15 typo + micro-fix Fix for one typo and micro-improvement for a property description --- 15.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to '15.md') diff --git a/15.md b/15.md index a3d105d..e8fe4af 100644 --- a/15.md +++ b/15.md @@ -137,13 +137,13 @@ The below json goes in content of [NIP04](https://github.com/nostr-protocol/nips "message": ", "contact": { "nostr": <32-bytes hex of a pubkey>, - "phone": , - "email": , + "phone": , + "email": , }, "items": [ { "product_id": , - "quantity": + "quantity": } ], "shipping_id": -- cgit v1.2.3 From 97b58ccc36a8360a099e4f905fc9bc616bc03f31 Mon Sep 17 00:00:00 2001 From: Yasuhiro Matsumoto Date: Fri, 14 Apr 2023 21:24:25 +0900 Subject: fix typos --- 15.md | 2 +- 51.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to '15.md') diff --git a/15.md b/15.md index e8fe4af..617c011 100644 --- a/15.md +++ b/15.md @@ -64,7 +64,7 @@ A merchant can publish these events: Fields that are not self-explanatory: - `shipping`: - an array with possible shipping zones for this stall. The customer MUST choose exactly one shipping zone. - - shipping to different zones can have different costs. For some goods (digital for examle) the cost can be zero. + - shipping to different zones can have different costs. For some goods (digital for example) the cost can be zero. - the `id` is an internal value used by the merchant. This value must be sent back as the customer selection. **Event Tags**: diff --git a/51.md b/51.md index 34a5def..80cc09e 100644 --- a/51.md +++ b/51.md @@ -97,11 +97,11 @@ Then the user would create a 'Categorized People' list event like below: ### Mute List -An event with kind `10000` is defined as a replaceable list event for listing content a user wants to mute. Any standarized tag can be included in a Mute List. +An event with kind `10000` is defined as a replaceable list event for listing content a user wants to mute. Any standardized tag can be included in a Mute List. ### Pin List -An event with kind `10001` is defined as a replaceable list event for listing content a user wants to pin. Any standarized tag can be included in a Pin List. +An event with kind `10001` is defined as a replaceable list event for listing content a user wants to pin. Any standardized tag can be included in a Pin List. ### Categorized People List @@ -109,4 +109,4 @@ An event with kind `30000` is defined as a parameterized replaceable list event ### Categorized Bookmarks List -An event with kind `30001` is defined as a parameterized replaceable list event for categorizing bookmarks. The 'd' parameter for this event holds the category name of the list. Any standarized tag can be included in a Categorized Bookmarks List. +An event with kind `30001` is defined as a parameterized replaceable list event for categorizing bookmarks. The 'd' parameter for this event holds the category name of the list. Any standardized tag can be included in a Categorized Bookmarks List. -- cgit v1.2.3