fix some smallities.

This adds an optional but recommended lud16 parameter to nostr wallet
connection strings. This enables seamless onboarding of new users,
allowing clients to automatically configure the receive address for
zaps.

01.md

@@ -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.
 
@@ -98,7 +99,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
 ## Basic Event Kinds
 
   - `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey.
-  - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say). Markdown links (`[]()` stuff) are not plaintext.
+  - `1`: `text_note`: the `content` is set to the plaintext content of a note (anything the user wants to say). Do not use Markdown! Clients should not have to guess how to interpret content like `[]()`. Use different event kinds for parsable content.
   - `2`: `recommend_server`: the `content` is set to the URL (e.g., `wss://somerelay.com`) of a relay the event creator wants to recommend to its followers.
 
 A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about.
@@ -106,5 +107,6 @@ 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.
+- Clients should use the created_at field to judge the age of a metadata event and completely replace older metadata events with newer metadata events regardless of the order in which they arrive.  Clients should not merge any filled fields within older metadata events into empty fields of newer metadata events.

04.md

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

05.md

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

06.md

@@ -8,8 +8,8 @@ Basic key derivation from mnemonic seed phrase
 
 [BIP39](https://bips.xyz/39) is used to generate mnemonic seed words and derive a binary seed from them.
 
-[BIP32](https://bips.xyz/32) is used to derive the path `m/44'/1237'/0'/0/0` (according to the Nostr entry on [SLIP44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)).
+[BIP32](https://bips.xyz/32) is used to derive the path `m/44'/1237'/<account>'/0/0` (according to the Nostr entry on [SLIP44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)).
 
-This is the default for a basic, normal, single-key client.
+A basic client can simply use an `account` of `0` to derive a single key. For more advanced use-cases you can increment `account`, allowing generation of practically infinite keys from the 5-level path with hardened derivation.
 
 Other types of clients can still get fancy and use other derivation paths for their own other purposes.

07.md

@@ -24,6 +24,7 @@ async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext
 
 ### Implementation
 
+- [horse](https://github.com/fiatjaf/horse) (Chrome and derivatives)
 - [nos2x](https://github.com/fiatjaf/nos2x) (Chrome and derivatives)
 - [Alby](https://getalby.com) (Chrome and derivatives, Firefox, Safari)
 - [Blockcore](https://www.blockcore.net/wallet) (Chrome and derivatives)

08.md

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

09.md

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

11.md

@@ -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,40 @@ 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" }],
   },
 ...
 }
+```
+
+### Examples ###
+As of 2 May 2023 the following `curl` command provided these results.
+
+	>curl -H "Accept: application/nostr+json" https://eden.nostr.land
+	
+	{"name":"eden.nostr.land",
+	"description":"Eden Nostr Land - Toronto 1-01",
+	"pubkey":"00000000827ffaa94bfea288c3dfce4422c794fbb96625b6b31e9049f729d700",
+	"contact":"me@ricardocabral.io",
+	"supported_nips":[1,2,4,9,11,12,15,16,20,22,26,28,33,40],
+	"supported_nip_extensions":["11a"],
+	"software":"git+https://github.com/Cameri/nostream.git",
+	"version":"1.22.6",
+	"limitation":{"max_message_length":1048576,
+				  "max_subscriptions":10,
+				  "max_filters":2500,
+				  "max_limit":5000,
+				  "max_subid_length":256,
+				  "min_prefix":4,
+				  "max_event_tags":2500,
+				  "max_content_length":65536,
+				  "min_pow_difficulty":0,
+				  "auth_required":false,
+				  "payment_required":true},
+	"payments_url":"https://eden.nostr.land/invoices",
+	"fees":{"admission":[{"amount":5000000,"unit":"msats"}],
+	        "publication":[]}}

13.md

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

15.md

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

18.md

@@ -0,0 +1,25 @@
+NIP-18
+======
+
+Reposts
+-------
+
+`draft` `optional` `author:jb55` `author:fiatjaf` `author:arthurfranca`
+
+A repost is a `kind 6` note that is used to signal to followers
+that another event is worth reading.
+
+The `content` of a repost event is empty. Optionally, it MAY contain
+the stringified JSON of the reposted note event for quick look up.
+
+The repost event MUST include an `e` tag with the `id` of the note that is
+being reposted. That tag MUST include a relay URL as its third entry
+to indicate where it can be fetched.
+
+The repost SHOULD include a `p` tag with the `pubkey` of the event being
+reposted.
+
+## Quote Reposts
+
+Quote reposts are `kind 1` events with an embedded `e` tag (see [NIP-08](08.md) and [NIP-27](27.md)).
+Because a quote repost includes an `e` tag, it may show up along replies to the reposted note.

19.md

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

21.md

@@ -1,16 +1,16 @@
 NIP-21
 ======
 
-`nostr:` URL scheme
+`nostr:` URI scheme
 -------------------
 
 `draft` `optional` `author:fiatjaf`
 
-This NIP standardizes the usage of a common URL scheme for maximum interoperability and openness in the network.
+This NIP standardizes the usage of a common URI scheme for maximum interoperability and openness in the network.
 
 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
 

22.md

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

25.md

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

26.md

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

27.md

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

40.md

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

45.md

@@ -0,0 +1,39 @@
+NIP-45
+======
+
+Event Counts
+--------------
+
+`draft` `optional` `author:staab`
+
+Relays may support the verb `COUNT`, which provides a mechanism for obtaining event counts.
+
+## Motivation
+
+Some queries a client may want to execute against connected relays are prohibitively expensive, for example, in order to retrieve follower counts for a given pubkey, a client must query all kind-3 events referring to a given pubkey only to count them. The result may be cached, either by a client or by a separate indexing server as an alternative, but both options erode the decentralization of the network by creating a second-layer protocol on top of Nostr.
+
+## Filters and return values
+
+This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
+
+```
+["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", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
+["COUNT", <subscription_id>, {"count": 238}]
+
+# Count posts and reactions
+["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
+["COUNT", <subscription_id>, {"count": 5}]
+```

47.md

@@ -0,0 +1,137 @@
+NIP-47
+======
+
+Nostr Wallet Connect
+--------------------
+
+`draft` `optional` `author:kiwiidb` `author:bumi` `author:semisol` `author:vitorpamplona`
+
+## Rationale
+
+This NIP describes a way for clients to access a remote Lightning wallet through a standardized protocol. Custodians may implement this, or the user may run a bridge that bridges their wallet/node and the Nostr Wallet Connect protocol.
+
+## Terms
+
+* **client**: Nostr app on any platform that wants to pay Lightning invoices.
+* **user**: The person using the **client**, and want's to connect their wallet app to their **client**.
+* **wallet service**: Nostr app that typically runs on an always-on computer (eg. in the cloud or on a Raspberry Pi).  This app has access to the APIs of the wallets it serves.
+
+## Theory of Operation
+ 1. **Users** who which to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application.  The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means. 
+ 
+ 2. The **user** should then copy this URI into their **client(s)** by pasting, or scanning the QR, etc.  The **client(s)** should save this URI and use it later whenever the **user** makes a payment.  The **client** should then request an `info` (13194) event from the relay(s) specified in the URI.  The **wallet service** will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.  
+ 
+ 3. When the **user** initiates a payment their nostr **client** create a `pay_invoice` request, encrypts it using a token from the URI, and sends it (kind 23194) to the relay(s) specified in the connection URI.  The **wallet service** will be listening on those relays and will decrypt the request and then contact the **user's** wallet application to send the payment.  The **wallet service** will know how to talk to the wallet application because the connection URI specified relay(s) that have access to the wallet app API.  
+ 
+ 4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI.  
+
+## Events
+
+There are three event kinds:
+- `NIP-47 info event`: 13194
+- `NIP-47 request`: 23194
+- `NIP-47 response`: 23195
+
+The info event should be a replaceable event that is published by the **wallet service** on the relay to indicate which commands it supports. The content should be
+a plaintext string with the supported commands, space-seperated, eg. `pay_invoice get_balance`. Only the `pay_invoice` command is described in this NIP, but other commands might be defined in different NIPs.
+
+Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to.
+
+The content of requests and responses is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure:
+
+Request:
+```jsonc
+{
+    "method": "pay_invoice", // method, string
+    "params": { // params, object
+        "invoice": "lnbc50n1..." // command-related data
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "pay_invoice", //indicates the structure of the result field
+    "error": { //object, non-null in case of error
+        "code": "UNAUTHORIZED", //string error code, see below
+        "message": "human readable error message"
+    },
+    "result": { // result, object. null in case of error.
+        "preimage": "0123456789abcdef..." // command-related data
+    }
+}
+```
+
+The `result_type` field MUST contain the name of the method that this event is responding to.
+The `error` field MUST contain a `message` field with a human readable error message and a `code` field with the error code if the command was not succesful.
+If the command was succesful, the `error` field must be null.
+
+### Error codes
+- `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds.
+- `NOT_IMPLEMENTED`: The command is not known or is intentionally not implemented.
+- `INSUFFICIENT_BALANCE`: The wallet does not have enough funds to cover a fee reserve or the payment amount.
+- `QUOTA_EXCEEDED`: The wallet has exceeded its spending quota.
+- `RESTRICTED`: This public key is not allowed to do this operation.
+- `UNAUTHORIZED`: This public key has no wallet connected.
+- `INTERNAL`: An internal error.
+- `OTHER`: Other error.
+
+## Nostr Wallet Connect URI
+**client** discovers **wallet service** by scanning a QR code, handling a deeplink or pasting in a URI.
+
+The **wallet service** generates this connection URI with protocol `nostr+walletconnect:` and base path it's hex-encoded `pubkey` with the following query string parameters: 
+
+- `relay` Required. URL of the relay where the **wallet service** is connected and will be listening for events. May be more than one.
+- `secret` Required. 32-byte randomly generated hex encoded string. The **client** MUST use this to sign events and encrypt payloads when communicating with the **wallet service**.
+    - Authorization does not require passing keys back and forth.
+    - The user can have different keys for different applications. Keys can be revoked and created at will and have arbitrary constraints (eg. budgets).
+    - The key is harder to leak since it is not shown to the user and backed up.
+    - It improves privacy because the user's main key would not be linked to their payments.
+- `lud16` Recommended. A lightning address that clients can use to automatically setup the `lud16` field on the user's profile if they have none configured.
+
+The **client** should then store this connection and use it when the user wants to perform actions like paying an invoice. Due to this NIP using ephemeral events, it is recommended to pick relays that do not close connections on inactivity to not drop events.
+
+### Example connection string
+```sh
+nostr+walletconnect:b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?relay=wss%3A%2F%2Frelay.damus.io&secret=71a8c14c1407c113601079c4302dab36460f0ccd0ad506f1f2dc73b5100e4f3c
+```
+
+## Commands
+
+### `pay_invoice`
+
+Description: Requests payment of an invoice.
+
+Request:
+```jsonc
+{
+    "method": "pay_invoice",
+    "params": {
+        "invoice": "lnbc50n1..." // bolt11 invoice
+    }
+}
+```
+
+Response:
+```jsonc
+{
+    "result_type": "pay_invoice",
+    "result": { 
+        "preimage": "0123456789abcdef..." // preimage of the payment
+    }
+}
+```
+
+Errors:
+- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.
+
+## Example pay invoice flow
+
+0. The user scans the QR code generated by the **wallet service** with their **client** application, they follow a `nostr+walletconnect:` deeplink or configure the connection details manually.
+1. **client** sends an event to the **wallet service** service with kind `23194`. The content is a `pay_invoice` request. The private key is the secret from the connection string above.
+2. **wallet service** verifies that the author's key is authorized to perform the payment, decrypts the payload and sends the payment.
+3. **wallet service** responds to the event by sending an event with kind `23195` and content being a response either containing an error message or a preimage.
+
+## Using a dedicated relay
+This NIP does not specify any requirements on the type of relays used. However, if the user is using a custodial service it might make sense to use a relay that is hosted by the custodial service. The relay may then enforce authentication to prevent metadata leaks. Not depending on a 3rd party relay would also improve reliability in this case.

51.md

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

57.md

@@ -6,69 +6,139 @@ Lightning Zaps
 
 `draft` `optional` `author:jb55` `author:kieran`
 
-This NIP defines a new note type called a lightning zap of kind `9735`. These represent paid lightning invoice receipts sent by a lightning node called the `zapper`. We also define another note type of kind `9734` which are `zap request` notes, which will be described in this document.
+This NIP defines two new event types for recording lightning payments between users. `9734` is a `zap request`, representing a payer's request to a recipient's lightning wallet for an invoice. `9735` is a `zap receipt`, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid.
 
 Having lightning receipts on nostr allows clients to display lightning payments from entities on the network. These can be used for fun or for spam deterrence.
 
-
-## Definitions
-
-`zapper` - the lightning node or service that sends zap notes (kind `9735`)
-
-`zap request` - a note of kind `9734` created by the person zapping
-
-`zap invoice` - the bolt11 invoice fetched from a custom lnurl endpoint which contains a `zap request` note
-
-
 ## Protocol flow
 
-### Client side
+1. Client calculates a recipient's lnurl pay request url from the `zap` tag on the event being zapped (see Appendix G), or by decoding their lud06 or lud16 field on their profile according to the [lnurl specifications](https://github.com/lnurl/luds). The client MUST send a GET request to this url and parse the response. If `allowsNostr` exists and it is `true`, and if `nostrPubkey` exists and is a valid BIP 340 public key in hex, the client should associate this information with the user, along with the response's `callback`, `minSendable`, and `maxSendable` values.
+2. Clients may choose to display a lightning zap button on each post or on a user's profile. If the user's lnurl pay request endpoint supports nostr, the client SHOULD use this NIP to request a zap receipt rather than a normal lnurl invoice.
+3. When a user (the "sender") indicates they want to send a zap to another user (the "recipient"), the client should create a `zap request` event as described in Appendix A of this NIP and sign it.
+4. Instead of publishing the `zap request`, the `9734` event should instead be sent to the `callback` url received from the lnurl pay endpoint for the recipient using a GET request. See Appendix B for details and an example.
+5. The recipient's lnurl server will receive this request and validate it. See Appendix C for details on how to properly configure an lnurl server to support zaps, and Appendix D for details on how to validate the `nostr` query parameter.
+6. If the request is valid, the server should fetch a description hash invoice where the description is this note and this note only. No additional lnurl metadata is included in the description. This will be returned in the response according to [LUD06](https://github.com/lnurl/luds/blob/luds/06.md).
+7. On receiving the invoice, the client MAY pay it or pass it to an app that can pay the invoice.
+8. Once the invoice is paid, the recipient's lnurl server MUST generate a `zap receipt` as described in Appendix E, and publish it to the `relays` specified in the `zap request`.
+9. Clients MAY fetch zap notes on posts and profiles, but MUST authorize their validity as described in Appendix F. If the zap request note contains a non-empty `content`, it may display a zap comment. Generally clients should show users the `zap request` note, and use the `zap note` to show "zap authorized by ..." but this is optional.
 
-1. Calculate the lnurl pay request url for a user from the lud06 or lud16 field on their profile
+## Reference and examples
 
-2. Fetch the lnurl pay request static endpoint (`https://host.com/.well-known/lnurlp/user`) and gather the `allowsNostr` and `nostrPubkey` fields. If `allowsNostr` exists and it is `true`, and if `nostrPubkey` exists and is a valid BIP 340 public key in hex, associate this information with the user. The `nostrPubkey` is the `zapper`'s pubkey, and it is used to authorize zaps sent to that user.
+### Appendix A: Zap Request Event
 
-3. Clients may choose to display a lightning zap button on each post or on the users profile, if the user's lnurl pay request endpoint supports nostr, the client SHOULD generate a `zap invoice` instead of a normal lnurl invoice.
+A `zap request` is an event of kind `9734` that is _not_ published to relays, but is instead sent to a recipient's lnurl pay `callback` url. This event's `content` MAY be an optional message to send along with the payment. The event MUST include the following tags:
 
-4. To generate a `zap invoice`, call the `callback` url with `amount` set to the milli-satoshi amount value. A `nostr` querystring value MUST be set as well. It is a uri-encoded `zap request` note signed by the user's key. The `zap request` note contains an `e` tag of the note it is zapping, and a `p` tag of the target user's pubkey. The `e` tag is optional which allows profile tipping. An optional `a` tag allows tipping parameterized replaceable events such as NIP-23 long-form notes. The `zap request` note must also have a `relays` tag, which is gathered from the user's configured relays. The `zap request` note SHOULD contain an `amount` tag, which is the milli-satoshi value of the zap which clients SHOULD verify being equal to the amount of the invoice. The `content` MAY be an additional comment from the user which can be displayed when listing zaps on posts and profiles.
+- `relays` is a list of relays the recipient's wallet should publish its `zap receipt` to. Note that relays should not be nested in an additional list, but should be included as shown in the example below.
+- `amount` is the amount in _millisats_ the sender intends to pay, formatted as a string. This is recommended, but optional.
+- `lnurl` is the lnurl pay url of the recipient, encoded using bech32 with the prefix `lnurl`. This is recommended, but optional.
+- `p` is the hex-encoded pubkey of the recipient.
 
-5. Pay this invoice or pass it to an app that can pay the invoice. Once it's paid, a `zap note` will be created by the `zapper`.
+In addition, the event MAY include the following tags:
 
-### LNURL Server side
+- `e` is an optional hex-encoded event id. Clients MUST include this if zapping an event rather than a person.
+- `a` is an optional NIP-33 event coordinate that allows tipping parameterized replaceable events such as NIP-23 long-form notes.
+
+Example:
+
+```json
+{
+  "kind": 9734,
+  "content": "Zap!",
+  "tags": [
+    ["relays", "wss://nostr-pub.wellorder.com"],
+    ["amount", "21000"],
+    ["lnurl", "lnurl1dp68gurn8ghj7um5v93kketj9ehx2amn9uh8wetvdskkkmn0wahz7mrww4excup0dajx2mrv92x9xp"],
+    ["p", "04c915daefee38317fa734444acee390a8269fe5810b2241e5e6dd343dfbecc9"],
+    ["e", "9ae37aa68f48645127299e9453eb5d908a0cbb6058ff340d528ed4d37c8994fb"]
+  ],
+  "pubkey": "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322",
+  "created_at": 1679673265,
+  "id": "30efed56a035b2549fcaeec0bf2c1595f9a9b3bb4b1a38abaf8ee9041c4b7d93",
+  "sig": "f2cb581a84ed10e4dc84937bd98e27acac71ab057255f6aa8dfa561808c981fe8870f4a03c1e3666784d82a9c802d3704e174371aa13d63e2aeaf24ff5374d9d"
+}
+```
+
+### Appendix B: Zap Request HTTP Request
+
+A signed zap request event is not published, but is instead sent using a HTTP GET request to the recipient's `callback` url, which was provided by the recipient's lnurl pay endpoint. This request should have the following query parameters defined:
+
+- `amount` is the amount in _millisats_ the sender intends to pay
+- `nostr` is the `9734` zap request event, JSON encoded then URI encoded
+- `lnurl` is the lnurl pay url of the recipient, encoded using bech32 with the prefix `lnurl`
+
+This request should return a JSON response with a `pr` key, which is the invoice the sender must pay to finalize his zap. Here is an example flow:
+
+```javascript
+const senderPubkey // The sender's pubkey
+const recipientPubkey = // The recipient's pubkey
+const callback = // The callback received from the recipients lnurl pay endpoint
+const lnurl = // The recipient's lightning address, encoded as a lnurl
+const sats = 21
+
+const amount = sats * 1000
+const relays = ['wss://nostr-pub.wellorder.net']
+const event = encodeURI(JSON.stringify(await signEvent({
+  kind: [9734],
+  content: "",
+  pubkey: senderPubkey,
+  created_at: Math.round(Date.now() / 1000),
+  tags: [
+    ["relays", ...relays],
+    ["amount", amount.toString()],
+    ["lnurl", lnurl],
+    ["p", recipientPubkey],
+  ],
+})))
+
+const {pr: invoice} = await fetchJson(`${callback}?amount=${amount}&nostr=${event}&lnurl=${lnurl}`)
+```
+
+### Appendix C: LNURL Server Configuration
 
 The lnurl server will need some additional pieces of information so that clients can know that zap invoices are supported:
 
-1. Add a `nostrPubkey` to the lnurl-pay static endpoint `/.well-known/lnurlp/user`, where `nostrPubkey` is the nostr pubkey of the `zapper`, the entity that creates zap notes. Clients will use this to authorize zaps.
-
+1. Add a `nostrPubkey` to the lnurl-pay static endpoint `/.well-known/lnurlp/<user>`, where `nostrPubkey` is the nostr pubkey your server will use to sign `zap receipt` events. Clients will use this to validate zap receipts.
 2. Add an `allowsNostr` field and set it to true.
 
-3. In the lnurl-pay callback URL, watch for a `nostr` querystring, where the contents of the note is a uri-encoded `zap request` JSON.
+### Appendix D: LNURL Server Zap Request Validation
 
-4. If present, the zap request note must be validated:
+When a client sends a zap request event to a server's lnurl-pay callback URL, there will be a `nostr` query parameter where the contents of the event are URI- and JSON-encoded. If present, the zap request event must be validated in the following ways:
 
-	a. It MUST have a valid nostr signature
+1. It MUST have a valid nostr signature
+2. It MUST have tags
+3. It MUST have only one `p` tag
+4. It MUST have 0 or 1 `e` tags
+5. There should be a `relays` tag with the relays to send the `zap` note to.
+6. If there is an `amount` tag, it MUST be equal to the `amount` query parameter.
+7. If there is an `a` tag, it MUST be a valid NIP-33 event coordinate
 
-	b. It MUST have tags
+The event MUST then be stored for use later, when the invoice is paid.
 
-	c. It MUST have at least one p-tag
+### Appendix E: Zap Receipt Event
 
-	d. It MUST have either 0 or 1 e-tag
+A `zap receipt` is created by a lightning node when an invoice generated by a `zap request` is paid. Zap receipts are only created when the invoice description (committed to the description hash) contains a zap request note.
 
-	e. There should be a `relays` tag with the relays to send the `zap` note to.
+When receiving a payment, the following steps are executed:
 
-	f. If there is an `amount` tag, it MUST be equal to the `amount` query parameter.
+1. Get the description for the invoice. This needs to be saved somewhere during the generation of the description hash invoice. It is saved automatically for you with CLN, which is the reference implementation used here.
+2. Parse the bolt11 description as a JSON nostr event. This SHOULD be validated based on the requirements in Appendix D, either when it is received, or before the invoice is paid.
+3. Create a nostr event of kind `9735` as described below, and publish it to the `relays` declared in the zap request.
 
-	g. If there is an `a` tag, it MUST be a valid NIP-33 event coordinate
+The following should be true of the zap receipt event:
 
-5. If valid, fetch a description hash invoice where the description is this note and this note only. No additional lnurl metadata is included in the description.
+- The content SHOULD be empty.
+- The `created_at` date SHOULD be set to the invoice `paid_at` date for idempotency.
+- `tags` MUST include the `p` tag AND optional `e` tag from the zap request.
+- The zap receipt MUST have a `bolt11` tag containing the description hash bolt11 invoice.
+- The zap receipt MUST contain a `description` tag which is the JSON-encoded invoice description.
+- `SHA256(description)` MUST match the description hash in the bolt11 invoice.
+- The zap receipt MAY contain a `preimage` tag to match against the payment hash of the bolt11 invoice. This isn't really a payment proof, there is no real way to prove that the invoice is real or has been paid. You are trusting the author of the zap receipt for the legitimacy of the payment.
 
-At this point, the lightning node is ready to send the zap note once payment is received.
+The zap receipt is not a proof of payment, all it proves is that some nostr user fetched an invoice. The existence of the zap receipt implies the invoice as paid, but it could be a lie given a rogue implementation.
 
-## The zap note
+A reference implementation for a zap-enabled lnurl server can be found [here](https://github.com/jb55/cln-nostr-zapper).
 
-Zap notes are created by a lightning node reacting to paid invoices. Zap notes are only created when the invoice description (committed to the description hash) contains a `zap request` note.
-
-Example zap note:
+Example zap receipt:
 
 ```json
 {
@@ -77,73 +147,36 @@ Example zap note:
     "created_at": 1674164545,
     "kind": 9735,
     "tags": [
-      [
-        "p",
-        "32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245"
-      ],
-      [
-        "e",
-        "3624762a1274dd9636e0c552b53086d70bc88c165bc4dc0f9e836a1eaf86c3b8"
-      ],
-      [
-        "bolt11",
-        "lnbc10u1p3unwfusp5t9r3yymhpfqculx78u027lxspgxcr2n2987mx2j55nnfs95nxnzqpp5jmrh92pfld78spqs78v9euf2385t83uvpwk9ldrlvf6ch7tpascqhp5zvkrmemgth3tufcvflmzjzfvjt023nazlhljz2n9hattj4f8jq8qxqyjw5qcqpjrzjqtc4fc44feggv7065fqe5m4ytjarg3repr5j9el35xhmtfexc42yczarjuqqfzqqqqqqqqlgqqqqqqgq9q9qxpqysgq079nkq507a5tw7xgttmj4u990j7wfggtrasah5gd4ywfr2pjcn29383tphp4t48gquelz9z78p4cq7ml3nrrphw5w6eckhjwmhezhnqpy6gyf0"
-      ],
-      [
-        "description",
-        "{\"pubkey\":\"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245\",\"content\":\"\",\"id\":\"d9cc14d50fcb8c27539aacf776882942c1a11ea4472f8cdec1dea82fab66279d\",\"created_at\":1674164539,\"sig\":\"77127f636577e9029276be060332ea565deaf89ff215a494ccff16ae3f757065e2bc59b2e8c113dd407917a010b3abd36c8d7ad84c0e3ab7dab3a0b0caa9835d\",\"kind\":9734,\"tags\":[[\"e\",\"3624762a1274dd9636e0c552b53086d70bc88c165bc4dc0f9e836a1eaf86c3b8\"],[\"p\",\"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245\"],[\"relays\",\"wss://relay.damus.io\",\"wss://nostr-relay.wlvs.space\",\"wss://nostr.fmt.wiz.biz\",\"wss://relay.nostr.bg\",\"wss://nostr.oxtr.dev\",\"wss://nostr.v0l.io\",\"wss://brb.io\",\"wss://nostr.bitcoiner.social\",\"ws://monad.jb55.com:8080\",\"wss://relay.snort.social\"]]}"
-      ],
-      [
-        "preimage",
-        "5d006d2cf1e73c7148e7519a4c68adc81642ce0e25a432b2434c99f97344c15f"
-      ]
+      ["p", "32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245"],
+      ["e", "3624762a1274dd9636e0c552b53086d70bc88c165bc4dc0f9e836a1eaf86c3b8"],
+      ["bolt11", "lnbc10u1p3unwfusp5t9r3yymhpfqculx78u027lxspgxcr2n2987mx2j55nnfs95nxnzqpp5jmrh92pfld78spqs78v9euf2385t83uvpwk9ldrlvf6ch7tpascqhp5zvkrmemgth3tufcvflmzjzfvjt023nazlhljz2n9hattj4f8jq8qxqyjw5qcqpjrzjqtc4fc44feggv7065fqe5m4ytjarg3repr5j9el35xhmtfexc42yczarjuqqfzqqqqqqqqlgqqqqqqgq9q9qxpqysgq079nkq507a5tw7xgttmj4u990j7wfggtrasah5gd4ywfr2pjcn29383tphp4t48gquelz9z78p4cq7ml3nrrphw5w6eckhjwmhezhnqpy6gyf0"],
+      ["description", "{\"pubkey\":\"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245\",\"content\":\"\",\"id\":\"d9cc14d50fcb8c27539aacf776882942c1a11ea4472f8cdec1dea82fab66279d\",\"created_at\":1674164539,\"sig\":\"77127f636577e9029276be060332ea565deaf89ff215a494ccff16ae3f757065e2bc59b2e8c113dd407917a010b3abd36c8d7ad84c0e3ab7dab3a0b0caa9835d\",\"kind\":9734,\"tags\":[[\"e\",\"3624762a1274dd9636e0c552b53086d70bc88c165bc4dc0f9e836a1eaf86c3b8\"],[\"p\",\"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245\"],[\"relays\",\"wss://relay.damus.io\",\"wss://nostr-relay.wlvs.space\",\"wss://nostr.fmt.wiz.biz\",\"wss://relay.nostr.bg\",\"wss://nostr.oxtr.dev\",\"wss://nostr.v0l.io\",\"wss://brb.io\",\"wss://nostr.bitcoiner.social\",\"ws://monad.jb55.com:8080\",\"wss://relay.snort.social\"]]}"],
+      ["preimage", "5d006d2cf1e73c7148e7519a4c68adc81642ce0e25a432b2434c99f97344c15f"]
     ],
     "content": "",
     "sig": "b0a3c5c984ceb777ac455b2f659505df51585d5fd97a0ec1fdb5f3347d392080d4b420240434a3afd909207195dac1e2f7e3df26ba862a45afd8bfe101c2b1cc"
   }
 ```
 
-* The zap note MUST have a `bolt11` tag containing the description hash bolt11 invoice.
+### Appendix F: Validating Zap Receipts
 
-* The zap note MUST contain a `description` tag which is the invoice description.
+A client can retrieve `zap receipts` on events and pubkeys using a NIP-01 filter, for example `{"kinds": [9735], "#e": [...]}`. Zaps MUST be validated using the following steps:
 
-* `SHA256(description)` MUST match the description hash in the bolt11 invoice.
+- The `zap receipt` event's `pubkey` MUST be the same as the recipient's lnurl provider's `nostrPubkey` (retrieved in step 1 of the protocol flow).
+- The `invoiceAmount` contained in the `bolt11` tag of the `zap receipt` MUST equal the `amount` tag of the `zap request` (if present).
+- The `lnurl` tag of the `zap request` (if present) SHOULD equal the recipient's `lnurl`.
 
-* The zap note MAY contain a `preimage` to match against the payment hash of the bolt11 invoice. This isn't really a payment proof, there is no real way to prove that the invoice is real or has been paid. You are trusting the author of the zap note for the legitimacy of the payment.
+### Appendix G: `zap` tag on zapped event
 
-The zap note is not a proof of payment, all it proves is that some nostr user fetched an invoice. The existence of the zap note implies the invoice as paid, but it could be a lie given a rogue implementation.
+When an event includes a `zap` tag, clients SHOULD calculate the lnurl pay request based on it's value instead of the profile's field. An optional third argument on the tag specifies the type of value, either `lud06` or `lud16`.
 
-
-### Creating a zap note
-
-When receiving a payment, the following steps are executed:
-
-1. Get the description for the invoice. This needs to be saved somewhere during the generation of the description hash invoice. It is saved automatically for you with CLN, which is the reference implementation used here.
-
-2. Parse the bolt11 description as a JSON nostr note. You SHOULD check the signature of the parsed note to ensure that it is valid. This is the `zap request` note created by the entity who is zapping.
-
-4. The note MUST have only one `p` tag
-
-5. The note MUST have 0 or 1 `e` tag
-
-6. Create a nostr note of kind `9735` that includes the `p` tag AND optional `e` tag. The content SHOULD be empty. The created_at date SHOULD be set to the invoice paid_at date for idempotency.
-
-7. Send the note to the `relays` declared in the `zap request` note from the invoice description.
-
-A reference implementation for the zapper is here: [zapper][zapper]
-
-[zapper]: https://github.com/jb55/cln-nostr-zapper
-
-
-## Client Behavior
-
-Clients MAY fetch zap notes on posts and profiles:
-
-`{"kinds": [9735], "#e": [...]}`
-
-To authorize these notes, clients MUST fetch the `nostrPubkey` from the users configured lightning address or lnurl and ensure that the zaps to their posts were created by this pubkey. If clients don't do this, anyone could forge unauthorized zaps.
-
-Once authorized, clients MAY tally zaps on posts, and list them on profiles. If the zap request note contains a non-empty `content`, it may display a zap comment. Generally clients should show users the `zap request` note, and use the `zap note` to show "zap authorized by ..." but this is optional.
+```json
+{
+    "tags": [
+        [ "zap", "pablo@f7z.io", "lud16" ]
+    ]
+}
+```
 
 ## Future Work
 

78.md

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

93.md

@@ -0,0 +1,180 @@
+NIP-93
+======
+
+NSON
+----
+
+`draft` `optional` `author:fiatjaf`
+
+### Preamble
+
+Some [benchmarks](https://github.com/fiatjaf/nostr-json-benchmarks/tree/2f254fff91b3ad063ef9726bb4a3d25316cf12d8) made using all libraries available on Golang show that JSON decoding is very slow. And even when people do assembly-level optimizations things only improve up to a point (e.g. for decoding a Nostr event, the "Sonic" library uses about 50% of that of the standard library).
+
+Meanwhile, doing a simple TLV encoding reduces the decoding time to 35% and a simpler static binary format for Nostr events makes that number drop to 4%. However, it would be bad for Nostr if a binary encoding was introduced, as it would be likely to cause compatibility issues, centralize the protocol and/or increase the work for everybody, more about this in [this comment](https://github.com/nostr-protocol/nips/pull/512#issuecomment-1542368664).
+
+### The actual NIP
+
+NSON is a crazy idea that, according to the benchmarks above, reduces the decoding time to 14% of that of the standard library. It works by having the JSON sender encode the event _as JSON_, but in a specific, very strict, order of fields (taking advantage of the fact that Nostr events have static fields, static lengths for some fields, and an overall rigid structure) and include in the JSON object a new field called `"nson"` that contains metadata the JSON receiver can read to help in the decoding process.
+
+Here's an example of a NSON-encoded Nostr event:
+
+`{"id":"57ff66490a6a2af3992accc26ae95f3f60c6e5f84ed0ddf6f59c534d3920d3d2","pubkey":"79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798","sig":"504d142aed7fa7e0f6dab5bcd7eed63963b0277a8e11bbcb03b94531beb4b95a12f1438668b02746bd5362161bc782068e6b71494060975414e793f9e19f57ea","created_at":1683762317,"nson":"2801000b0203000100400005040001004000000014","kind":1,"content":"hello world","tags":[["e","b6de44a9dd47d1c000f795ea0453046914f44ba7d5e369608b04867a575ea83e","reply"],["p","c26f7b252cea77a5b94f42b1a4771021be07d4df766407e47738605f7e3ab774","","wss://relay.damus.io"]]}`
+
+The idea is that `"id"` comes first, so it can be accessed by reading a slice of the string from character `7` to character `71`, `pubkey` from character `83` to `147` and so on. `"content"`, `"kind"` and `"tags"` have dynamic sizes, so their sizes are given by the values inside the `"nson"` field (which is also dynamic, its size given by its first byte).
+
+### Anatomy of the `"nson"` field
+
+It is hex-encoded. Some fields are a single byte, others are two bytes (4 characters), big-endian.
+
+                    tt: number of tags (let's say it's two)
+                      nn: number of items on the first tag (let's say it's 3)
+                        1111: number of chars on the first item
+                            2222: number of chars on the second item
+                                3333: number of chars on the third item
+                                    nn: number of items on the second tag (let's say it's 2)
+                                      1111: number of chars on the first item
+                                          2222: number of chars on the second item
+    "nson":"xxkkccccttnn111122223333nn11112222"
+            xx: nson size
+              kk: kind chars
+                cccc: content chars
+
+### Reference implementation
+
+```go
+func decodeNson(data string) *Event {
+	evt := &Event{}
+
+	// static fields
+	evt.ID = data[7 : 7+64]
+	evt.PubKey = data[83 : 83+64]
+	evt.Sig = data[156 : 156+128]
+	ts, _ := strconv.ParseInt(data[299:299+10], 10, 64)
+	evt.CreatedAt = Timestamp(ts)
+
+	// nson values
+	nsonSizeBytes, _ := hex.DecodeString(data[318 : 318+2])
+	nsonSize := int(nsonSizeBytes[0])
+	nsonDescriptors, _ := hex.DecodeString(data[320 : 320+nsonSize])
+
+	// dynamic fields
+	// kind
+	kindChars := int(nsonDescriptors[0])
+	kindStart := 320 + nsonSize + 9 // len(`","kind":`)
+	evt.Kind, _ = strconv.Atoi(data[kindStart : kindStart+kindChars])
+
+	// content
+	contentChars := int(binary.BigEndian.Uint16(nsonDescriptors[1:3]))
+	contentStart := kindStart + kindChars + 12 // len(`,"content":"`)
+	evt.Content, _ = strconv.Unquote(`"` + data[contentStart:contentStart+contentChars] + `"`)
+
+	// tags
+	nTags := int(nsonDescriptors[3])
+	evt.Tags = make(Tags, nTags)
+	tagsStart := contentStart + contentChars + 9 // len(`","tags":`)
+
+	nsonIndex := 3
+	tagsIndex := tagsStart
+	for t := 0; t < nTags; t++ {
+		nsonIndex++
+		tagsIndex += 1 // len(`[`) or len(`,`)
+		nItems := int(nsonDescriptors[nsonIndex])
+		tag := make(Tag, nItems)
+		for n := 0; n < nItems; n++ {
+			nsonIndex++
+			itemStart := tagsIndex + 2 // len(`["`) or len(`,"`)
+			itemChars := int(binary.BigEndian.Uint16(nsonDescriptors[nsonIndex:]))
+			nsonIndex++
+			tag[n], _ = strconv.Unquote(`"` + data[itemStart:itemStart+itemChars] + `"`)
+			tagsIndex = itemStart + itemChars + 1 // len(`"`)
+		}
+		tagsIndex += 1 // len(`]`)
+		evt.Tags[t] = tag
+	}
+
+	return evt
+}
+
+func encodeNson(evt *Event) string {
+	// start building the nson descriptors (without the first byte that represents the nson size)
+	nsonBuf := make([]byte, 256)
+
+	// build the tags
+	nTags := len(evt.Tags)
+	nsonBuf[3] = uint8(nTags)
+	nsonIndex := 3 // start here
+
+	tagBuilder := strings.Builder{}
+	tagBuilder.Grow(1000) // a guess
+	tagBuilder.WriteString(`[`)
+	for t, tag := range evt.Tags {
+		nItems := len(tag)
+		nsonIndex++
+		nsonBuf[nsonIndex] = uint8(nItems)
+
+		tagBuilder.WriteString(`[`)
+		for i, item := range tag {
+			v := strconv.Quote(item)
+			nsonIndex++
+			binary.BigEndian.PutUint16(nsonBuf[nsonIndex:], uint16(len(v)-2))
+			nsonIndex++
+			tagBuilder.WriteString(v)
+			if nItems > i+1 {
+				tagBuilder.WriteString(`,`)
+			}
+		}
+		tagBuilder.WriteString(`]`)
+		if nTags > t+1 {
+			tagBuilder.WriteString(`,`)
+		}
+	}
+	tagBuilder.WriteString(`]}`)
+	nsonBuf = nsonBuf[0 : nsonIndex+1]
+
+	kind := strconv.Itoa(evt.Kind)
+	kindChars := len(kind)
+	nsonBuf[0] = uint8(kindChars)
+
+	content := strconv.Quote(evt.Content)
+	contentChars := len(content) - 2
+	binary.BigEndian.PutUint16(nsonBuf[1:3], uint16(contentChars))
+
+	// actually build the json
+	base := strings.Builder{}
+	base.Grow(320 + // everything up to "nson":
+		2 + len(nsonBuf)*2 + // nson
+		9 + kindChars + // kind and its label
+		12 + contentChars + // content and its label
+		9 + tagBuilder.Len() + // tags and its label
+		2, // the end
+	)
+	base.WriteString(`{"id":"` + evt.ID + `","pubkey":"` + evt.PubKey + `","sig":"` + evt.Sig + `","created_at":` + strconv.FormatInt(int64(evt.CreatedAt), 10) + `,"nson":"`)
+	base.WriteString(hex.EncodeToString([]byte{uint8(len(nsonBuf) * 2)})) // nson size
+	base.WriteString(hex.EncodeToString(nsonBuf))                         // nson descriptors
+	base.WriteString(`","kind":` + kind + `,"content":` + content + `,"tags":`)
+	base.WriteString(tagBuilder.String() /* includes the end */)
+
+	return base.String()
+}
+```
+
+### Other restrictions
+
+Besides the field ordering and the presence of the `"nson"` field, other restrictions must be applied:
+
+- the `"created_at"` field must have 10, characters, which gives us a range of dates from about 20 years ago up to 250 years in the future.
+- to simplify decoding of `"content"` and `"tags"` strings, escape codes like `\uXXXX` are forbidden in NSON, UTF-8 must be used instead. `\n`, `\\` and `\"` are the only valid escaped sequences.
+
+### Backwards-compatibility
+
+Any reader who is not aware of the NSON-encoding can receive these events and decode them using whatever means they want. The `"nson"` field will just be ignored and life will continue as normal.
+
+Also, other event fields that may be present (for example, the NIP-03 `"ots"` field) can be added at the end, after `"tags"`, with no loss to anyone.
+
+### Other points worth mentioning
+
+- Relays can receive non-nsonified events from clients, then reformat and store them nsonified so they can serve future clients better by sending them NSON always.
+
+### Open questions to be edited out of the NIP
+
+- How to signal NSON support? I thought it would work to have an initial field `"n":1` (before `"id"`) on the JSON, which could be read very fast, but I don't know.

94.md

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

README.md

@@ -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/nostr-protocol/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,15 +26,16 @@ 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)
 - [NIP-20: Command Results](20.md)
 - [NIP-21: `nostr:` URL scheme](21.md)
@@ -32,7 +50,9 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 - [NIP-39: External Identities in Profiles](39.md)
 - [NIP-40: Expiration Timestamp](40.md)
 - [NIP-42: Authentication of clients to relays](42.md)
+- [NIP-45: Counting results](45.md)
 - [NIP-46: Nostr Connect](46.md)
+- [NIP-47: Wallet Connect](47.md)
 - [NIP-50: Keywords filter](50.md)
 - [NIP-51: Lists](51.md)
 - [NIP-56: Reporting](56.md)
@@ -40,80 +60,116 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 - [NIP-58: Badges](58.md)
 - [NIP-65: Relay List Metadata](65.md)
 - [NIP-78: Application-specific data](78.md)
+- [NIP-94: File Metadata](94.md)
 
 ## Event Kinds
 
-| 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)  |
-| 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) |
-| 1984          | Reporting                        | [56](56.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) |
+| `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) |
+| `13194` | Wallet Info                | [47](47.md) |
+| `22242` | Client Authentication      | [42](42.md) |
+| `23194` | Wallet Request             | [47](47.md) |
+| `23195` | Wallet Response            | [47](47.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) |
+
+| 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) |
+
+| 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)              |
+| 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)              |
+| `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