From 3d8652ea147facb07adb51031e6b21f7e663dc10 Mon Sep 17 00:00:00 2001 From: Alex Gleason Date: Mon, 1 Jan 2024 12:21:50 -0600 Subject: [PATCH 1/7] NIP-02, NIP-51: new tags should be added to the end of the list Fixes https://github.com/nostr-protocol/nips/issues/958 --- 02.md | 2 ++ 51.md | 2 ++ 2 files changed, 4 insertions(+) diff --git a/02.md b/02.md index 8c47a5f7..8b0aee15 100644 --- a/02.md +++ b/02.md @@ -27,6 +27,8 @@ For example: Every new following list that gets published overwrites the past ones, so it should contain all entries. Relays and clients SHOULD delete past following lists as soon as they receive a new one. +Whenever new follows are added to an existing list, clients SHOULD append them to the end of the list, so they are stored in chronological order. + ## Uses ### Follow list backup diff --git a/51.md b/51.md index f5a9a749..507c515a 100644 --- a/51.md +++ b/51.md @@ -10,6 +10,8 @@ This NIP defines lists of things that users can create. Lists can contain refere Public items in a list are specified in the event `tags` array, while private items are specified in a JSON array that mimics the structure of the event `tags` array, but stringified and encrypted using the same scheme from [NIP-04](04.md) (the shared key is computed using the author's public and private key) and stored in the `.content`. +When new items are added to an existing list, clients SHOULD append them to the end of the list, so they are stored in chronological order. + ## Types of lists ## Standard lists From 56610771b6b0c61b2269fc16f163a004b585f726 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ioan=20Biz=C4=83u?= Date: Tue, 9 Jan 2024 13:35:40 +0200 Subject: [PATCH 2/7] Add auctions to NIP-15. (#859) * Add auctions to NIP-15. * Update 15.md Co-authored-by: Vlad Stan * Address comments from @motorina0. * Remove reference to removed type=10. --------- Co-authored-by: Vlad Stan --- 15.md | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 77 insertions(+), 1 deletion(-) diff --git a/15.md b/15.md index 1c3154a3..e2ba639c 100644 --- a/15.md +++ b/15.md @@ -149,7 +149,6 @@ The `merchant` and the `customer` can exchange JSON messages that represent diff | 1 | Merchant | Payment Request | | 2 | Merchant | Order Status Update | - ### Step 1: `customer` order (event) The below json goes in content of [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md). @@ -229,7 +228,9 @@ The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/ni "shipped": , } ``` + ## Customize Marketplace + Create 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. ### Event `30019`: Create or update marketplace UI/UX @@ -253,6 +254,81 @@ Create a customized user experience using the `naddr` from [NIP-19](https://gith This event leverages naddr to enable comprehensive customization and sharing of marketplace configurations, fostering a unique and engaging marketplace environment. +## Auctions + +### Event `30020`: Create or update a product sold as an auction + +**Event Content**: +```json +{ + "id": , + "stall_id": , + "name": , + "description": , + "images": <[String], array of image URLs, optional>, + "starting_bid": , + "start_date": , + "duration": , + "specs": [ + [, ] + ], + "shipping": [ + { + "id": , + "cost": , + } + ] +} +``` + +> [!NOTE] +> Items sold as an auction are very similar in structure to fixed-price items, with some important differences worth noting. + +* 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. + +* The auction runs for an initial number of seconds after the `start_date`, specified by `duration`. + +### Event `1021`: Bid + +```json +{ + "content": , + "tags": [["e", ]], +} +``` + +Bids are simply events of kind `1021` with a `content` field specifying the amount, in the currency of the auction. Bids must reference an auction. + +> [!NOTE] +> 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! + +### Event `1022`: Bid confirmation + +**Event Content**: + +```json +{ + "status": , + "message": , + "duration_extended": , +} +``` + +**Event Tags**: +```json + "tags": [["e" ], ["e", ]], +``` + +Bids 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). + +The `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. + +The 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. + +An additional `message` field can appear in the `content` JSON to give further context as of why a bid is `rejected` or `pending`. + +Another 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`. + ## 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. From 8331354947f2d577e13eb5da4a56133071cb1019 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Wed, 10 Jan 2024 10:43:30 -0300 Subject: [PATCH 3/7] remove NIP-52 label cruft. --- 52.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/52.md b/52.md index 4ec68369..5ac116b9 100644 --- a/52.md +++ b/52.md @@ -187,10 +187,8 @@ The `.content` of these events is optional and should be a free-form note that a The list of tags are as follows: * `a` (required) reference tag to kind `31922` or `31923` calendar event being responded to. * `d` (required) universally unique identifier. Generated by the client creating the calendar event RSVP. -* `L` (required) label namespace of `status` per [NIP-32](32.md) -* `l` (required) label of `accepted`, `declined`, or `tentative` under the label namespace of `status` per [NIP-32](32.md). Determines attendance status to the referenced calendar event. -* `L` (optional) label namespace of `freebusy` per [NIP-32](32.md). Exists if and only if corresponding `l` tag under the same label namespace exists. -* `l` (optional) label of `free` or `busy` under the label namespace of `freebusy` per [NIP-32](32.md). Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`. Exists if and only if corresponding `l` tag under the same label namespace exists. +* `status` (required) `accepted`, `declined`, or `tentative`. Determines attendance status to the referenced calendar event. +* `fb` (optional) `free` or `busy`. Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`. ```json { @@ -202,10 +200,8 @@ The list of tags are as follows: "tags": [ ["a", "<31922 or 31923>::", ""], ["d", ""], - ["L", "status"], - ["l", "", "status"], - ["L", "freebusy"], - ["l", "", "freebusy"] + ["status", ""], + ["fb", ""], ] } ``` From 4b4e9fabfd66a3200222b3b2e71946c2640e701f Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Sat, 13 Jan 2024 01:23:01 +0900 Subject: [PATCH 4/7] Add kind and tag for NIP-96 --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 678818d5..cf3827e8 100644 --- a/README.md +++ b/README.md @@ -118,6 +118,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `10007` | Search relays list | [51](51.md) | | `10015` | Interests list | [51](51.md) | | `10030` | User emoji list | [51](51.md) | +| `10096` | File storage server list | [96](96.md) | | `13194` | Wallet Info | [47](47.md) | | `21000` | Lightning Pub RPC | [Lightning.Pub][lnpub] | | `22242` | Client Authentication | [42](42.md) | @@ -220,6 +221,7 @@ Please update these lists when proposing NIPs introducing new event kinds. | `published_at` | unix timestamp (string) | -- | [23](23.md) | | `relay` | relay url | -- | [42](42.md) | | `relays` | relay list | -- | [57](57.md) | +| `server` | file storage server url | -- | [96](96.md) | | `subject` | subject | -- | [14](14.md) | | `summary` | article summary | -- | [23](23.md) | | `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) | From 20d33785fc2e2884f28bece04e4fab679b621ec8 Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Sat, 13 Jan 2024 03:46:59 +0900 Subject: [PATCH 5/7] Remove NIP-54 mention temporarily (#981) * Remove NIP-54 mention temporarily * Update 96.md Co-authored-by: arthurfranca --------- Co-authored-by: arthurfranca --- 96.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/96.md b/96.md index 661bd45e..d8ea105e 100644 --- a/96.md +++ b/96.md @@ -189,7 +189,7 @@ Note that if the server didn't apply any transformation to the received file, bo `Clients` may upload the same file to one or many `servers`. After successful upload, the `client` may optionally generate and send to any set of nostr `relays` a [NIP-94](94.md) event by including the missing fields. -Alternatively, instead of using NIP-94, the `client` can share or embed on a nostr note just the above url with added "ox" [NIP-54](54.md) inline metadata field and optionally other ones. +Alternatively, instead of using NIP-94, the `client` can share or embed on a nostr note just the above url. ### Delayed Processing From d8d75d9b19e6c66f7d75c771e784cd9dee4d2320 Mon Sep 17 00:00:00 2001 From: Asai Toshiya Date: Tue, 16 Jan 2024 23:28:23 +0900 Subject: [PATCH 6/7] Fix some minor nitpicks in NIP-15 and NIP-51 --- 15.md | 20 ++++++++++---------- 51.md | 14 +++++++------- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/15.md b/15.md index e2ba639c..55814fb5 100644 --- a/15.md +++ b/15.md @@ -56,7 +56,7 @@ A merchant can publish these events: "id": , "name": , "cost": , - "regions": [], + "regions": [] } ] } @@ -101,7 +101,7 @@ Fields that are not self-explanatory: "shipping": [ { "id": , - "cost": , + "cost": } ] } @@ -139,7 +139,7 @@ Fields that are not self-explanatory: ## Checkout events -All checkout events are sent as JSON strings using ([NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md)). +All checkout events are sent as JSON strings using ([NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md)). The `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: @@ -150,19 +150,19 @@ The `merchant` and the `customer` can exchange JSON messages that represent diff | 2 | Merchant | Order Status Update | ### Step 1: `customer` order (event) -The below json goes in content of [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md). +The below JSON goes in content of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md). ```json { "id": , "type": 0, "name": , - "address": + "address": , "message": ", "contact": { "nostr": <32-bytes hex of a pubkey>, "phone": , - "email": , + "email": }, "items": [ { @@ -182,7 +182,7 @@ _Open_: is `contact.nostr` required? 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). +The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md). `payment_options`/`type` include: @@ -217,7 +217,7 @@ The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/ni 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). +The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md). ```json { @@ -275,7 +275,7 @@ This event leverages naddr to enable comprehensive customization and sharing of "shipping": [ { "id": , - "cost": , + "cost": } ] } @@ -310,7 +310,7 @@ Bids are simply events of kind `1021` with a `content` field specifying the amou { "status": , "message": , - "duration_extended": , + "duration_extended": } ``` diff --git a/51.md b/51.md index 47ed8991..9a1639f8 100644 --- a/51.md +++ b/51.md @@ -18,18 +18,18 @@ When new items are added to an existing list, clients SHOULD append them to the Standard lists use non-parameterized replaceable events, meaning users may only have a single list of each kind. They have special meaning and clients may rely on them to augment a user's profile or browsing experience. -For example, _mute lists_ can contain the public keys of spammers and bad actors users don't want to see in their feeds or receive annoying notifications from. +For example, _mute list_ can contain the public keys of spammers and bad actors users don't want to see in their feeds or receive annoying notifications from. | name | kind | description | expected tag items | | --- | --- | --- | --- | | Mute list | 10000 | things the user doesn't want to see in their feeds | `"p"` (pubkeys), `"t"` (hashtags), `"word"` (lowercase string), `"e"` (threads) | | Pinned notes | 10001 | events the user intends to showcase in their profile page | `"e"` (kind:1 notes) | -| Bookmarks | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r" (URLs)` | +| Bookmarks | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) | | Communities | 10004 | [NIP-72](72.md) communities the user belongs to | `"a"` (kind:34550 community definitions) | -| Public chats | 10005 | [NIP-28](28.md) chat channels the user is in | `"e"` (kind:40 channel definitions) | +| Public chats | 10005 | [NIP-28](28.md) chat channels the user is in | `"e"` (kind:40 channel definitions) | | Blocked relays | 10006 | relays clients should never connect to | `"relay"` (relay URLs) | | Search relays | 10007 | relays clients should use when performing search queries | `"relay"` (relay URLs) | -| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a" (kind:30015 interest set)` | +| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) | | Emojis | 10030 | user preferred emojis and pointers to emoji sets | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set) | ## Sets @@ -44,9 +44,9 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti | --- | --- | --- | --- | | Follow sets | 30000 | categorized groups of users a client may choose to check out in different circumstances | `"p"` (pubkeys) | | Relay sets | 30002 | user-defined relay groups the user can easily pick and choose from during various operations | `"relay"` (relay URLs) | -| Bookmark sets | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r" (URLs)` | +| Bookmark sets | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) | | Curation sets | 30004 | groups of articles picked by users as interesting and/or belonging to the same category | `"a"` (kind:30023 articles), `"e"` (kind:1 notes) | -| Curation sets | 30005 | groups of videos picked by users as interesting and/or belonging to the same category | `"a"` (kind:34235 videos) | +| Curation sets | 30005 | groups of videos picked by users as interesting and/or belonging to the same category | `"a"` (kind:34235 videos) | | Interest sets | 30015 | interest topics represented by a bunch of "hashtags" | `"t"` (hashtags) | | Emoji sets | 30030 | categorized emoji groups | `"emoji"` (see [NIP-30](30.md)) | @@ -82,7 +82,7 @@ Some clients have used these lists in the past, but they should work on transiti ### A _curation set_ of articles and notes about yaks -``` +```json { "id": "567b41fc9060c758c4216fe5f8d3df7c57daad7ae757fa4606f0c39d4dd220ef", "pubkey": "d6dc95542e18b8b7aec2f14610f55c335abebec76f3db9e58c254661d0593a0c", From 9b39fd5ef51eefc85af99b5aefac1a109bc17de3 Mon Sep 17 00:00:00 2001 From: Thabokani <149070269+Thabokani@users.noreply.github.com> Date: Wed, 17 Jan 2024 16:09:50 +0800 Subject: [PATCH 7/7] NIP-96: fix typo --- 96.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/96.md b/96.md index d8ea105e..3ebbef83 100644 --- a/96.md +++ b/96.md @@ -273,7 +273,7 @@ The `server` should reject deletes from users other than the original uploader. It should be noted that more than one user may have uploaded the same file (with the same hash). In this case, a delete must not really delete the file but just remove the user's `pubkey` from the file owners list (considering the server keeps just one copy of the same file, because multiple uploads of the same file results in the same file hash). -The successfull response is a 200 OK one with just basic JSON fields: +The successful response is a 200 OK one with just basic JSON fields: ``` {