nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-25 09:45:51 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'nostr-protocol:master' into versatile-data

Browse Source
This commit is contained in:
ティル父さん 2024-01-18 18:04:26 +09:00 committed by GitHub
commit dcb1046e12
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
6 changed files with 104 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
02.md
View File

@ -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

94
15.md
View File

@ -56,7 +56,7 @@ A merchant can publish these events:
"id": <string, id of the shipping zone, generated by the merchant>,
"name": <string (optional), zone name>,
"cost": <float, base cost for shipping. The currency is defined at the stall level>,
"regions": [<string, regions included in this zone>],
"regions": [<string, regions included in this zone>]
}
]
}
@ -101,7 +101,7 @@ Fields that are not self-explanatory:
"shipping": [
{
"id": <string, id of the shipping zone (must match one of the zones defined for the stall)>,
"cost": <float, extra cost for shipping. The currency is defined at the stall level>,
"cost": <float, extra cost for shipping. The currency is defined at the stall level>
}
]
}
@ -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:
@ -149,21 +149,20 @@ 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).
The below JSON goes in content of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md).
```json
{
"id": <string, id generated by the customer>,
"type": 0,
"name": <string (optional), ???>,
"address": <string (optional), for physical goods an address should be provided>
"address": <string (optional), for physical goods an address should be provided>,
"message": "<string (optional), message for merchant>,
"contact": {
"nostr": <32-bytes hex of a pubkey>,
"phone": <string (optional), if the customer wants to be contacted by phone>,
"email": <string (optional), if the customer wants to be contacted by email>,
"email": <string (optional), if the customer wants to be contacted by email>
},
"items": [
{
@ -183,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:
@ -218,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
{
@ -229,7 +228,9 @@ The below json goes in `content` of [NIP04](https://github.com/nostr-protocol/ni
"shipped": <bool: has been 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": <String, UUID generated by the merchant. Sequential IDs (`0`, `1`, `2`...) are discouraged>,
"stall_id": <String, UUID of the stall to which this product belong to>,
"name": <String, product name>,
"description": <String (optional), product description>,
"images": <[String], array of image URLs, optional>,
"starting_bid": <int>,
"start_date": <int (optional) UNIX timestamp, date the auction started / will start>,
"duration": <int, number of seconds the auction will run for, excluding eventual time extensions that might happen>,
"specs": [
[<String, spec key>, <String, spec value>]
],
"shipping": [
{
"id": <String, UUID of the shipping zone. Must match one of the zones defined for the stall>,
"cost": <float, extra cost for shipping. The currency is defined at the stall level>
}
]
}
```
> [!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": <int, amount of sats>,
"tags": [["e", <event ID of the auction to bid on>]],
}
```
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": <String, "accepted" | "rejected" | "pending" | "winner">,
"message": <String (optional)>,
"duration_extended": <int (optional), number of seconds>
}
```
**Event Tags**:
```json
"tags": [["e" <event ID of the bid being confirmed>], ["e", <event ID of the auction>]],
```
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.

12
51.md
View File

@ -10,24 +10,26 @@ 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
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) |
| 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
@ -42,7 +44,7 @@ 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) |
| Interest sets | 30015 | interest topics represented by a bunch of "hashtags" | `"t"` (hashtags) |
@ -80,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",

12
52.md
View File

@ -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>:<calendar event author pubkey>:<d-identifier of calendar event>", "<optional relay url>"],
["d", "<UUID>"],
["L", "status"],
["l", "<accepted/declined/tentative>", "status"],
["L", "freebusy"],
["l", "<free/busy>", "freebusy"]
["status", "<accepted/declined/tentative>"],
["fb", "<free/busy>"],
]
}
```

4
96.md
View File

@ -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
@ -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:
```
{

2
README.md
View File

@ -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) |