nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-13 23:39:08 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'nostr-protocol/master'

Browse Source 
# Conflicts:
#	README.md
This commit is contained in:
toadlyBroodle 2023-04-29 13:20:49 +09:00
commit 678f0c03aa
20 changed files with 494 additions and 159 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
01.md
View File

@ -4,7 +4,7 @@ NIP-01
Basic protocol flow description
-------------------------------
`draft` `mandatory` `author:fiatjaf` `author:distbit` `author:scsibug` `author:kukks` `author:jb55`
`draft` `mandatory` `author:fiatjaf` `author:distbit` `author:scsibug` `author:kukks` `author:jb55` `author:semisol`
This 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.
@ -86,10 +86,11 @@ The `limit` property of a filter is only valid for the initial query and can be
### From relay to client: sending events and notices
Relays can send 2 types of messages, which must also be JSON arrays, according to the following patterns:
Relays can send 3 types of messages, which must also be JSON arrays, according to the following patterns:
* `["EVENT", <subscription_id>, <event JSON as defined above>]`, used to send events requested by clients.
* `["NOTICE", <message>]`, used to send human-readable error messages or other things to clients.
* `["EOSE", <subscription_id>]`, used to indicate the _end of stored events_ and the beginning of events newly received in real-time.
* `["NOTICE", <message>]`, used to send human-readable error messages or other things to clients.
This NIP defines no rules for how `NOTICE` messages should be sent or treated.
@ -106,5 +107,5 @@ A relay may choose to treat different message kinds differently, and it may or m
## Other Notes:
- Clients should not open more than one websocket to each relay. One channel can support an unlimited number of subscriptions, so clients should do that.
- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow.
- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow. See [NIP-10](https://github.com/nostr-protocol/nips/blob/127d5518bfa9a4e4e7510490c0b8d95e342dfa4b/10.md) for a detailed description of "e" and "p" tags.
- The `<recommended relay URL>` item present on the `"e"` and `"p"` tags is an optional (could be set to `""`) URL of a relay the client could attempt to connect to fetch the tagged event or other events from a tagged profile. It MAY be ignored, but it exists to increase censorship resistance and make the spread of relay addresses more seamless across clients.

2
04.md
View File

@ -50,4 +50,4 @@ This standard does not go anywhere near what is considered the state-of-the-art
## Client Implementation Warning
Client's *should not* search and replace public key or note references from the `.content`. If processed like a regular text note (where `@npub...` is replaced with `#[0]` with a `["p", "..."]` tag) the tags are leaked and the mentioned user will receive the message in their inbox.
Clients *should not* search and replace public key or note references from the `.content`. If processed like a regular text note (where `@npub...` is replaced with `#[0]` with a `["p", "..."]` tag) the tags are leaked and the mentioned user will receive the message in their inbox.

2
05.md
View File

@ -64,7 +64,7 @@ For example, if after finding that `bob@bob.com` has the public key `abc...def`,
### Public keys must be in hex format
Keys must be returned in hex format. Keys in NIP-19 `npub` format are are only meant to be used for display in client UIs, not in this NIP.
Keys must be returned in hex format. Keys in NIP-19 `npub` format are only meant to be used for display in client UIs, not in this NIP.
### User Discovery implementation suggestion

2
08.md
View File

@ -1,4 +1,4 @@
> __Warning__ `unrecommended`: deprecated in favor of NIP-27
> __Warning__ `unrecommended`: deprecated in favor of [NIP-27](27.md)
NIP-08
======

4
09.md
View File

@ -27,13 +27,13 @@ For example:
}
```
Relays SHOULD delete or stop publishing any referenced events that have an identical `id` as the deletion request. Clients SHOULD hide or otherwise indicate a deletion status for referenced events.
Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request. Clients SHOULD hide or otherwise indicate a deletion status for referenced events.
Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion events to other relays which don't have it.
## Client Usage
Clients MAY choose to fully hide any events that are referenced by valid deletion events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the deleted event's own content, although a user interface should clearly indicate that this is a deletion reason, not the original content.
Clients MAY choose to fully hide any events that are referenced by valid deletion events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion reason, not the original content.
A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey`, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative.

61
11.md
View File

@ -69,18 +69,18 @@ are rejected or fail immediately.
```json
{
...
limitation: {
max_message_length: 16384,
max_subscriptions: 20,
max_filters: 100,
max_limit: 5000,
max_subid_length: 100,
min_prefix: 4,
max_event_tags: 100,
max_content_length: 8196,
min_pow_difficulty: 30,
auth_required: true,
payment_required: true,
"limitation": {
"max_message_length": 16384,
"max_subscriptions": 20,
"max_filters": 100,
"max_limit": 5000,
"max_subid_length": 100,
"min_prefix": 4,
"max_event_tags": 100,
"max_content_length": 8196,
"min_pow_difficulty": 30,
"auth_required": true,
"payment_required": true,
}
...
}
@ -141,11 +141,11 @@ all, and preferably an error will be provided when those are received.
```json
{
...
retention: [
{ kinds: [0, 1, [5, 7], [40, 49]], time: 3600 },
{ kinds: [[40000, 49999], time: 100 },
{ kinds: [[30000, 39999], count: 1000 },
{ time: 3600, count: 10000 }
"retention": [
{ "kinds": [0, 1, [5, 7], [40, 49]], "time": 3600 },
{ "kinds": [[40000, 49999]], "time": 100 },
{ "kinds": [[30000, 39999]], "count": 1000 },
{ "time": 3600, "count": 10000 }
]
...
}
@ -154,7 +154,7 @@ all, and preferably an error will be provided when those are received.
`retention` is a list of specifications: each will apply to either all kinds, or
a subset of kinds. Ranges may be specified for the kind field as a tuple of inclusive
start and end values. Events of indicated kind (or all) are then limited to a `count`
and or time period.
and/or time period.
It is possible to effectively blacklist Nostr-based protocols that rely on
a specific `kind` number, by giving a retention time of zero for those `kind` values.
@ -175,8 +175,8 @@ It is not possible to describe the limitations of each country's laws
and policies which themselves are typically vague and constantly shifting.
Therefore, this field allows the relay operator to indicate which
country's' laws might end up being enforced on them, and then
indirectly on their users's content.
countries' laws might end up being enforced on them, and then
indirectly on their users' content.
Users should be able to avoid relays in countries they don't like,
and/or select relays in more favourable zones. Exposing this
@ -185,7 +185,7 @@ flexibility is up to the client software.
```json
{
...
relay_countries: [ 'CA', 'US' ],
"relay_countries": [ "CA", "US" ],
...
}
```
@ -208,9 +208,9 @@ To support this goal, relays MAY specify some of the following values.
```json
{
...
language_tags: [ 'en', 'en-419' ],
tags: [ 'sfw-only', 'bitcoin-only', 'anime' ],
posting_policy: 'https://example.com/posting-policy.html',
"language_tags": [ "en", "en-419" ],
"tags": [ "sfw-only", "bitcoin-only", "anime" ],
"posting_policy": "https://example.com/posting-policy.html",
...
}
```
@ -220,7 +220,7 @@ To support this goal, relays MAY specify some of the following values.
the major languages spoken on the relay.
- `tags` is a list of limitations on the topics to be discussed.
For example `sfw-only` indicates hat only "Safe For Work" content
For example `sfw-only` indicates that only "Safe For Work" content
is encouraged on this relay. This relies on assumptions of what the
"work" "community" feels "safe" talking about. In time, a common
set of tags may emerge that allow users to find relays that suit
@ -245,11 +245,12 @@ Relays that require payments may want to expose their fee schedules.
```json
{
...
payments_url: "https://my-relay/payments",
fees: {
"admission": [{ amount: 1000000, unit: 'msats' }],
"subscription": [{ amount: 5000000, unit: 'msats', period: 2592000 }],
"publication": [{ kinds: [4], amount: 100, unit: 'msats' }],
"payments_url": "https://my-relay/payments",
"fees": {
"admission": [{ "amount": 1000000, "unit": "msats" }],
"subscription": [{ "amount": 5000000, "unit": "msats", "period": 2592000 }],
"publication": [{ "kinds": [4], "amount": 100, "unit": "msats" }],
},
...
}
```

76
13.md
View File

@ -10,13 +10,15 @@ This NIP defines a way to generate and interpret Proof of Work for nostr notes.
`difficulty` is defined to be the number of leading zero bits in the `NIP-01` id. For example, an id of `000000000e9d97a1ab09fc381030b346cdd7a142ad57e6df0b46dc9bef6c7e2d` has a difficulty of `36` with `36` leading 0 bits.
`002f...` is `0000 0000 0010 1111...` in binary, which has 10 leading zeroes. Do not forget to count leading zeroes for hex digits <= `7`.
Mining
------
To generate PoW for a `NIP-01` note, a `nonce` tag is used:
```json
{"content": "It's just me mining my own business", "tags": [["nonce", "1", "20"]]}
{"content": "It's just me mining my own business", "tags": [["nonce", "1", "21"]]}
```
When mining, the second entry to the nonce tag is updated, and then the id is recalculated (see [NIP-01](./01.md)). If the id has the desired number of leading zero bits, the note has been mined. It is recommended to update the `created_at` as well during this process.
@ -36,7 +38,7 @@ Example mined note
[
"nonce",
"776797",
"20"
"21"
]
],
"content": "It's just me mining my own business",
@ -47,33 +49,61 @@ Example mined note
Validating
----------
Here is some reference C code for calculating the difficulty (aka number of leading zero bits) in a nostr note id:
Here is some reference C code for calculating the difficulty (aka number of leading zero bits) in a nostr event id:
```c
int zero_bits(unsigned char b)
{
int n = 0;
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
if (b == 0)
return 8;
int countLeadingZeroes(const char *hex) {
int count = 0;
while (b >>= 1)
n++;
for (int i = 0; i < strlen(hex); i++) {
int nibble = (int)strtol((char[]){hex[i], '\0'}, NULL, 16);
if (nibble == 0) {
count += 4;
} else {
count += __builtin_clz(nibble) - 28;
break;
}
}
return 7-n;
return count;
}
/* find the number of leading zero bits in a hash */
int count_leading_zero_bits(unsigned char *hash)
{
int bits, total, i;
for (i = 0, total = 0; i < 32; i++) {
bits = zero_bits(hash[i]);
total += bits;
if (bits != 8)
break;
}
return total;
int main(int argc, char *argv[]) {
if (argc != 2) {
fprintf(stderr, "Usage: %s <hex_string>\n", argv[0]);
return 1;
}
const char *hex_string = argv[1];
int result = countLeadingZeroes(hex_string);
printf("Leading zeroes in hex string %s: %d\n", hex_string, result);
return 0;
}
```
Here is some JavaScript code for doing the same thing:
```javascript
// hex should be a hexadecimal string (with no 0x prefix)
function countLeadingZeroes(hex) {
let count = 0;
for (let i = 0; i < hex.length; i++) {
const nibble = parseInt(hex[i], 16);
if (nibble === 0) {
count += 4;
} else {
count += Math.clz32(nibble) - 28;
break;
}
}
return count;
}
```
@ -90,4 +120,4 @@ $ echo '["REQ", "subid", {"ids": ["000000000"]}]' | websocat wss://some-relay.c
Delegated Proof of Work
-----------------------
Since the `NIP-01` note id does not commit to any signature, PoW can be outsourced to PoW providers, perhaps for a fee. This provides a way for clients to get their messages out to PoW-restricted relays without having to do any work themselves, which is useful for energy constrained devices like on mobile
Since the `NIP-01` note id does not commit to any signature, PoW can be outsourced to PoW providers, perhaps for a fee. This provides a way for clients to get their messages out to PoW-restricted relays without having to do any work themselves, which is useful for energy-constrained devices like mobile phones.

215
15.md
View File

@ -1,21 +1,214 @@
NIP-15
======
End of Stored Events Notice
---------------------------
Nostr Marketplace (for resilient marketplaces)
-----------------------------------
`final` `optional` `author:Semisol`
`draft` `optional` `author:fiatjaf` `author:benarc` `author:motorina0` `author:talvasconcelos`
Relays may support notifying clients when all stored events have been sent.
> Based on https://github.com/lnbits/Diagon-Alley
If a relay supports this NIP, the relay SHOULD send the client a `EOSE` message in the format `["EOSE", <subscription_id>]` after it has sent all the events it has persisted and it indicates all the events that come after this message are newly published.
> Implemented here https://github.com/lnbits/nostrmarket
Client Behavior
---------------
## Terms
Clients SHOULD use the `supported_nips` field to learn if a relay supports end of stored events notices.
- `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`
Motivation
----------
## Nostr Marketplace Clients
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.
### 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": <String, UUID generated by the merchant. Sequential IDs (`0`, `1`, `2`...) are discouraged>,
"name": <String, stall name>,
"description": <String (optional), stall description>,
"currency": <String, currency used>,
"shipping": [
{
"id": <String, UUID of the shipping zone, generated by the merchant>,
"name": <String (optional), zone name>,
"cost": <float, cost for shipping. The currency is defined at the stall level>,
"countries": [<String, countries included in this zone>],
}
]
}
```
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 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**:
```json
"tags": [["d", <String, id of stall]]
```
- the `d` tag is required by [NIP33](https://github.com/nostr-protocol/nips/blob/master/33.md). Its value MUST be the same as the stall `id`.
### Event `30018`: Create or update a product
**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>,
"currency": <String, currency used>,
"price": <float, cost of product>,
"quantity": <int, available items>,
"specs": [
[ <String, spec key>, <String, spec value>]
]
}
```
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", <String, id of product],
["t", <String (optional), product category],
["t", <String (optional), product category],
...
]
```
- the `d` tag is required by [NIP33](https://github.com/nostr-protocol/nips/blob/master/33.md). Its value MUST be the same as the product `id`.
- the `t` tag is as searchable tag ([NIP12](https://github.com/nostr-protocol/nips/blob/master/12.md)). It represents different categories that the product can be part of (`food`, `fruits`). Multiple `t` tags can be present.
## Checkout events
All checkout events are sent as JSON strings using ([NIP04](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:
| Message Type | Sent By | Description |
|--------------|----------|---------------------|
| 0 | Customer | New Order |
| 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).
```json
{
"id": <String, UUID generated by the customer>,
"type": 0,
"name": <String (optional), ???>,
"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>,
},
"items": [
{
"product_id": <String, UUID of the product>,
"quantity": <int, how many products the customer is ordering>
}
],
"shipping_id": <String, UUID of the shipping zone>
}
```
_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": <String, UUID of the order>,
"type": 1,
"message": <String, message to customer, optional>,
"payment_options": [
{
"type": <String, option type>,
"link": <String, url, btc address, ln invoice, etc>
},
{
"type": <String, option type>,
"link": <String, url, btc address, ln invoice, etc>
},
{
"type": <String, option type>,
"link": <String, url, btc address, ln invoice, etc>
}
]
}
```
### 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": <String, UUID of the order>,
"type": 2,
"message": <String, message to customer>,
"paid": <Bool, true/false has received payment>,
"shipped": <Bool, true/false has been 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 <a href="https://raw.githubusercontent.com/lnbits/nostrmarket/main/models.py">here</a>

2
19.md
View File

@ -53,6 +53,7 @@ These possible standardized `TLV` types are indicated here:
- for `nevent`, _optionally_, the 32 bytes of the pubkey of the event
- `3`: `kind`
- for `naddr`, the 32-bit unsigned integer of the kind, big-endian
- for `nevent`, _optionally_, the 32-bit unsigned integer of the kind, big-endian
## Examples
@ -66,3 +67,4 @@ These possible standardized `TLV` types are indicated here:
## Notes
- `npub` keys MUST NOT be used in NIP-01 events or in NIP-05 JSON responses, only the hex format is supported there.
- When decoding a bech32-formatted string, TLVs that are not recognized or supported should be ignored, rather than causing an error.

2
21.md
View File

@ -10,7 +10,7 @@ This NIP standardizes the usage of a common URL scheme for maximum interoperabil
The scheme is `nostr:`.
The identifiers that come after are expected to be the same as those defined in NIP-19 (except `nsec`).
The identifiers that come after are expected to be the same as those defined in [NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md) (except `nsec`).
## Examples

2
22.md
View File

@ -22,7 +22,7 @@ This NIP formalizes restrictions on event timestamps as accepted by a relay and
The event `created_at` field is just a unix timestamp and can be set to a time in the past or future. Relays accept and share events dated to 20 years ago or 50,000 years in the future. This NIP aims to define a way for relays that do not want to store events with *any* timestamp to set their own restrictions.
[Replaceable events](16.md#replaceable-events) can behave rather unexpected if the user wrote them - or tried to write them - with a wrong system clock. Persisting an update with a backdated system now would result in the update not getting persisted without a notification and if they did the last update with a forward dated system, they will again fail to do another update with the now correct time.
[Replaceable events](16.md#replaceable-events) can behave rather unexpectedly if the user wrote them - or tried to write them - with a wrong system clock. Persisting an update with a backdated system now would result in the update not getting persisted without a notification and if they did the last update with a forward dated system, they will again fail to do another update with the now correct time.
A wide adoption of this NIP could create a better user experience as it would decrease the amount of events that appear wildly out of order or even from impossible dates in the distant past or future.

2
25.md
View File

@ -16,7 +16,7 @@ A reaction with `content` set to `-` SHOULD be interpreted as a "dislike" or
"downvote". It SHOULD NOT be counted as a "like", and MAY be displayed as a
downvote or dislike on a post. A client MAY also choose to tally likes against
dislikes in a reddit-like system of upvotes and downvotes, or display them as
separate tallys.
separate tallies.
The `content` MAY be an emoji, in this case it MAY be interpreted as a "like" or "dislike",
or the client MAY display this emoji reaction on the post.

6
26.md
View File

@ -101,6 +101,8 @@ The event should be considered a valid delegation if the conditions are satisfie
Clients should display the delegated note as if it was published directly by the delegator (8e0d3d3e).
#### Relay & Client Querying Support
#### Relay & Client Support
Relays should answer requests such as `["REQ", "", {"authors": ["A"]}]` by querying both the `pubkey` and delegation tags `[1]` value.
Relays should answer requests such as `["REQ", "", {"authors": ["A"]}]` by querying both the `pubkey` and delegation tags `[1]` value.
Relays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf).

4
27.md
View File

@ -8,11 +8,11 @@ Text Note References
This 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).
When creating an event, clients should include mentions to other profiles and to other events in the middle of the `.content` using NIP-21 codes, such as `nostr:nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg`.
When creating an event, clients should include mentions to other profiles and to other events in the middle of the `.content` using [NIP-21](21.md) codes, such as `nostr:nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg`.
Including [NIP-10](10.md)-style tags (`["e", <hex-id>, <relay-url>, <marker>]`) for each reference is optional, clients should do it whenever they want the profile being mentioned to be notified of the mention, or when they want the referenced event to recognize their mention as a reply.
A reader client that receives an event with such `nostr:...` mentions in its `.content` can do any desired context augmentation (for example, linking to the profile or showing a preview of the mentioned event contents) it wants in the process. If turning such mentions into links, they could become internal links, NIP-21 links or direct links to web clients that will handle these references.
A reader client that receives an event with such `nostr:...` mentions in its `.content` can do any desired context augmentation (for example, linking to the profile or showing a preview of the mentioned event contents) it wants in the process. If turning such mentions into links, they could become internal links, [NIP-21](21.md) links or direct links to web clients that will handle these references.
---

2
40.md
View File

@ -43,7 +43,7 @@ Clients SHOULD ignore events that have expired.
Relay Behavior
--------------
Relays MAY NOT delete an expired message immediately on expiration and MAY persist them indefinitely.
Relays MAY NOT delete expired messages immediately on expiration and MAY persist them indefinitely.
Relays SHOULD NOT send expired events to clients, even if they are stored.
Relays SHOULD drop any events that are published to them if they are expired.
An expiration timestamp does not affect storage of ephemeral events.

20
45.md
View File

@ -6,7 +6,7 @@ Event Counts
`draft` `optional` `author:staab`
Relays may support the `COUNT` verb, which provide a mechanism for obtaining event counts.
Relays may support the `COUNT` verb, which provides a mechanism for obtaining event counts.
## Motivation
@ -14,18 +14,26 @@ Some queries a client may want to execute against connected relays are prohibiti
## Filters and return values
This NIP defines a verb called `COUNT`, which accepts a subscription id and a filter as specified in [NIP 01](01.md).
This NIP defines a verb called `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md).
```
["COUNT", <subscription_id>, <filters JSON>...]
```
Counts are returned using a `COUNT` response in the form `{count: <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
```
["COUNT", <subscription_id>, {"count": <integer>}]
```
Examples:
```
# Followers count
["COUNT", "", {kinds: [3], '#p': [<pubkey>]}]
["COUNT", "", {count: 238}]
["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
["COUNT", <subscription_id>, {"count": 238}]
# Count posts and reactions
["COUNT", "", {kinds: [1, 7], authors: [<pubkey>]}]
["COUNT", "", {count: 5}]
["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
["COUNT", <subscription_id>, {"count": 5}]
```

8
51.md
View File

@ -10,7 +10,7 @@ A "list" event is defined as having a list of public and/or private tags. Public
If a list type should only be defined once per user (like the 'Mute' list), the list type's events should follow the specification for [NIP-16 - Replaceable Events](16.md). These lists may be referred to as 'replaceable lists'.
Otherwise the list type's events should follow the specification for [NIP-33 - Parameterized Replaceable Events](33.md), where the list name will be used as the 'd' parameter. These lists may be referred to as 'parameterized replaceable lists'.
Otherwise, the list type's events should follow the specification for [NIP-33 - Parameterized Replaceable Events](33.md), where the list name will be used as the 'd' parameter. These lists may be referred to as 'parameterized replaceable lists'.
## Replaceable List Event Example
@ -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.

2
78.md
View File

@ -8,7 +8,7 @@ Arbitrary custom app data
The goal of this NIP is to enable [remoteStorage](https://remotestorage.io/)-like capabilities for custom applications that do not care about interoperability.
Even though interoperability is great, some apps do not want or do not need interoperability, and it that wouldn't make sense for them. Yet Nostr can still serve as a generalized data storage for these apps in a "bring your own database" way, for example: a user would open an app and somehow input their preferred relay for storage, which would then enable these apps to store application-specific data there.
Even though interoperability is great, some apps do not want or do not need interoperability, and it wouldn't make sense for them. Yet Nostr can still serve as a generalized data storage for these apps in a "bring your own database" way, for example: a user would open an app and somehow input their preferred relay for storage, which would then enable these apps to store application-specific data there.
## Nostr event

51
94.md Normal file
View File

@ -0,0 +1,51 @@
NIP-94
======
File Metadata
-------------
`draft` `optional` `author:frbitten` `author:kieran` `author:lovvtide` `author:fiatjaf` `author:staab`
The 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.
## Event format
This NIP specifies the use of the `1063` event type, having in `content` a description of the file content, and a list of tags described below:
* `url` the url to download the file
* `m` a string indicating the data type of the file. The MIME types format must be used (https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types)
* `"aes-256-gcm"` (optional) key and nonce for AES-GCM encryption with tagSize always 128bits
* `x` containing the SHA-256 hexencoded string of the file.
* `size` (optional) size of file in bytes
* `dim` (optional) size of file in pixels in the form `<width>x<height>`
* `magnet` (optional) URI to magnet file
* `i` (optional) torrent infohash
* `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the file is being loaded by the client
```json
{
"id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>,
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
"created_at": <unix timestamp in seconds>,
"kind": 1063,
"tags": [
["url",<string with URI of file>],
["aes-256-gcm",<key>, <iv>],
["m", <MIME type>],
["x",<Hash SHA-256>],
["size", <size of file in bytes>],
["dim", <size of file in pixels>],
["magnet",<magnet URI> ],
["i",<torrent infohash>],
["blurhash", <value>]
],
"content": <description>,
"sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
}
```
## Suggested use cases
* A relay for indexing shared files. For example, to promote torrents.
* A pinterest-like client where people can share their portfolio and inspire others.
* A simple way to distribute configurations and software updates.

181
README.md
View File

@ -1,6 +1,23 @@
# NIPs
NIPs stand for **Nostr Implementation Possibilities**. They exist to document what may be implemented by [Nostr](https://github.com/fiatjaf/nostr)-compatible _relay_ and _client_ software.
NIPs stand for **Nostr Implementation Possibilities**.
They exist to document what may be implemented by [Nostr](https://github.com/fiatjaf/nostr)-compatible _relay_ and _client_ software.
---
- [List](#list)
- [Event Kinds](#event-kinds)
- [Event Kind Ranges](#event-kind-ranges)
- [Message Types](#message-types)
- [Client to Relay](#client-to-relay)
- [Relay to Client](#relay-to-client)
- [Standardized Tags](#standardized-tags)
- [Criteria for acceptance of NIPs](#criteria-for-acceptance-of-nips)
- [License](#license)
---
## List
- [NIP-01: Basic protocol flow description](01.md)
- [NIP-02: Contact List and Petnames](02.md)
@ -9,14 +26,14 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
- [NIP-05: Mapping Nostr keys to DNS-based internet identifiers](05.md)
- [NIP-06: Basic key derivation from mnemonic seed phrase](06.md)
- [NIP-07: `window.nostr` capability for web browsers](07.md)
- [NIP-08: Handling Mentions](08.md) – `unrecommended`: deprecated in favor of [NIP-27](27.md)
- [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md)
- [NIP-09: Event Deletion](09.md)
- [NIP-10: Conventions for clients' use of `e` and `p` tags in text events](10.md)
- [NIP-11: Relay Information Document](11.md)
- [NIP-12: Generic Tag Queries](12.md)
- [NIP-13: Proof of Work](13.md)
- [NIP-14: Subject tag in text events.](14.md)
- [NIP-15: End of Stored Events Notice](15.md)
- [NIP-15: Nostr Marketplace (for resilient marketplaces)](15.md)
- [NIP-16: Event Treatment](16.md)
- [NIP-18: Reposts](18.md)
- [NIP-19: bech32-encoded entities](19.md)
@ -43,85 +60,115 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
- [NIP-65: Relay List Metadata](65.md)
- [NIP-69: Polls](69.md)
- [NIP-78: Application-specific data](78.md)
- [NIP-94: File Metadata](94.md)
## Event Kinds
| kind | description | NIP |
| ------------- | -------------------------------- | ----------------------- |
| 0 | Metadata | [1](01.md), [5](05.md) |
| 1 | Short Text Note | [1](01.md) |
| 2 | Recommend Relay | [1](01.md) |
| 3 | Contacts | [2](02.md) |
| 4 | Encrypted Direct Messages | [4](04.md) |
| 5 | Event Deletion | [9](09.md) |
| 7 | Reaction | [25](25.md) |
| 8 | Badge Award | [58](58.md) |
| 40 | Channel Creation | [28](28.md) |
| 41 | Channel Metadata | [28](28.md) |
| 42 | Channel Message | [28](28.md) |
| 43 | Channel Hide Message | [28](28.md) |
| 44 | Channel Mute User | [28](28.md) |
| 45-49 | Public Chat Reserved | [28](28.md) |
| 1984 | Reporting | [56](56.md) |
| 6969 | Poll | [69](69.md) |
| 9734 | Zap Request | [57](57.md) |
| 9735 | Zap | [57](57.md) |
| 10000 | Mute List | [51](51.md) |
| 10001 | Pin List | [51](51.md) |
| 10002 | Relay List Metadata | [65](65.md) |
| 22242 | Client Authentication | [42](42.md) |
| 24133 | Nostr Connect | [46](46.md) |
| 30000 | Categorized People List | [51](51.md) |
| 30001 | Categorized Bookmark List | [51](51.md) |
| 30008 | Profile Badges | [58](58.md) |
| 30009 | Badge Definition | [58](58.md) |
| 30023 | Long-form Content | [23](23.md) |
| 30078 | Application-specific Data | [78](78.md) |
| 1000-9999 | Regular Events | [16](16.md) |
| 10000-19999 | Replaceable Events | [16](16.md) |
| 20000-29999 | Ephemeral Events | [16](16.md) |
| 30000-39999 | Parameterized Replaceable Events | [33](33.md) |
| kind | description | NIP |
| ------- | -------------------------- | ----------- |
| `0` | Metadata | [1](01.md) |
| `1` | Short Text Note | [1](01.md) |
| `2` | Recommend Relay | [1](01.md) |
| `3` | Contacts | [2](02.md) |
| `4` | Encrypted Direct Messages | [4](04.md) |
| `5` | Event Deletion | [9](09.md) |
| `6` | Reposts | [18](18.md) |
| `7` | Reaction | [25](25.md) |
| `8` | Badge Award | [58](58.md) |
| `40` | Channel Creation | [28](28.md) |
| `41` | Channel Metadata | [28](28.md) |
| `42` | Channel Message | [28](28.md) |
| `43` | Channel Hide Message | [28](28.md) |
| `44` | Channel Mute User | [28](28.md) |
| `1063` | File Metadata | [94](94.md) |
| `1984` | Reporting | [56](56.md) |
| `6969` | Poll | [69](69.md) |
| `9734` | Zap Request | [57](57.md) |
| `9735` | Zap | [57](57.md) |
| `10000` | Mute List | [51](51.md) |
| `10001` | Pin List | [51](51.md) |
| `10002` | Relay List Metadata | [65](65.md) |
| `22242` | Client Authentication | [42](42.md) |
| `24133` | Nostr Connect | [46](46.md) |
| `30000` | Categorized People List | [51](51.md) |
| `30001` | Categorized Bookmark List | [51](51.md) |
| `30008` | Profile Badges | [58](58.md) |
| `30009` | Badge Definition | [58](58.md) |
| `30017` | Create or update a stall | [15](15.md) |
| `30018` | Create or update a product | [15](15.md) |
| `30023` | Long-form Content | [23](23.md) |
| `30078` | Application-specific Data | [78](78.md) |
### Event Kind Ranges
| range | description | NIP |
| ---------------- | -------------------------------- | ----------- |
| `1000`--`9999` | Regular Events | [16](16.md) |
| `10000`--`19999` | Replaceable Events | [16](16.md) |
| `20000`--`29999` | Ephemeral Events | [16](16.md) |
| `30000`--`39999` | Parameterized Replaceable Events | [33](33.md) |
## Message types
### Client to Relay
| type | description | NIP |
|-------|-----------------------------------------------------|-------------|
| EVENT | used to publish events | [1](01.md) |
| REQ | used to request events and subscribe to new updates | [1](01.md) |
| CLOSE | used to stop previous subscriptions | [1](01.md) |
| AUTH | used to send authentication events | [42](42.md) |
| COUNT | used to request event counts | [45](45.md) |
| type | description | NIP |
| ------- | --------------------------------------------------- | ----------- |
| `AUTH` | used to send authentication events | [42](42.md) |
| `CLOSE` | used to stop previous subscriptions | [1](01.md) |
| `COUNT` | used to request event counts | [45](45.md) |
| `EVENT` | used to publish events | [1](01.md) |
| `REQ` | used to request events and subscribe to new updates | [1](01.md) |
### Relay to Client
| type | description | NIP |
|--------|---------------------------------------------------------|-------------|
| EVENT | used to send events requested to clients | [1](01.md) |
| NOTICE | used to send human-readable messages to clients | [1](01.md) |
| EOSE | used to notify clients all stored events have been sent | [15](15.md) |
| OK | used to notify clients if an EVENT was successful | [20](20.md) |
| AUTH | used to send authentication challenges | [42](42.md) |
| COUNT | used to send requested event counts to clients | [45](45.md) |
| type | description | NIP |
| -------- | ------------------------------------------------------- | ----------- |
| `AUTH` | used to send authentication challenges | [42](42.md) |
| `COUNT` | used to send requested event counts to clients | [45](45.md) |
| `EOSE` | used to notify clients all stored events have been sent | [1](01.md) |
| `EVENT` | used to send events requested to clients | [1](01.md) |
| `NOTICE` | used to send human-readable messages to clients | [1](01.md) |
| `OK` | used to notify clients if an EVENT was successful | [20](20.md) |
Please update these lists when proposing NIPs introducing new event kinds.
When experimenting with kinds, keep in mind the classification introduced by [NIP-16](16.md).
When experimenting with kinds, keep in mind the classification introduced by [NIP-16](16.md) and [NIP-33](33.md).
## Standardized Tags
| name | value | other parameters | NIP |
| ------------| ------------------------- | ----------------- | ------------------------ |
| e | event id (hex) | relay URL, marker | [1](01.md), [10](10.md) |
| p | pubkey (hex) | relay URL | [1](01.md) |
| a | coordinates to an event | relay URL | [33](33.md), [23](23.md) |
| r | a reference (URL, etc) | | [12](12.md) |
| t | hashtag | | [12](12.md) |
| g | geohash | | [12](12.md) |
| nonce | random | | [13](13.md) |
| subject | subject | | [14](14.md) |
| d | identifier | | [33](33.md) |
| expiration | unix timestamp (string) | | [40](40.md) |
| poll_option | option key value (string) | | [57](57.md), [69](69.md) |
| name | value | other parameters | NIP |
|-------------------|--------------------------------------|----------------------| ------------------------ |
| `a` | coordinates to an event | relay URL | [33](33.md), [23](23.md) |
| `d` | identifier | -- | [33](33.md) |
| `e` | event id (hex) | relay URL, marker | [1](01.md), [10](10.md) |
| `g` | geohash | -- | [12](12.md) |
| `i` | identity | proof | [39](39.md) |
| `p` | pubkey (hex) | relay URL | [1](01.md) |
| `r` | a reference (URL, etc) | -- | [12](12.md) |
| `t` | hashtag | -- | [12](12.md) |
| `amount` | millisats | -- | [57](57.md) |
| `bolt11` | `bolt11` invoice | -- | [57](57.md) |
| `challenge` | challenge string | -- | [42](42.md) |
| `content-warning` | reason | -- | [36](36.md) |
| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
| `description` | badge description | -- | [58](58.md) |
| `description` | invoice description | -- | [57](57.md) |
| `expiration` | unix timestamp (string) | -- | [40](40.md) |
| `image` | image URL | dimensions in pixels | [23](23.md), [58](58.md) |
| `lnurl` | `bech32` encoded `lnurl` | -- | [57](57.md) |
| `name` | badge name | -- | [58](58.md) |
| `nonce` | random | -- | [13](13.md) |
| `poll_option` | option key value (string) | -- | [57](57.md), [69](69.md) |
| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
| `published_at` | unix timestamp (string) | -- | [23](23.md) |
| `relay` | relay url | -- | [42](42.md) |
| `relays` | relay list | -- | [57](57.md) |
| `subject` | subject | -- | [14](14.md) |
| `summary` | article summary | -- | [23](23.md) |
| `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) |
| `title` | article title | -- | [23](23.md) |
| `zap` | profile name | type of value | [57](57.md) |
## Criteria for acceptance of NIPs