up

01.md

@@ -77,11 +77,11 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
 
 - The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>]`
 - The `p` tag, used to refer to another user: `["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]`
-- The `a` tag, used to refer to a (maybe parameterized) replaceable event
+- The `a` tag, used to refer to an addressable or replaceable event
     - for an addressable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
     - for a normal replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
 
-As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter.
+As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter. Only the first value in any given tag is indexed.
 
 ### Kinds
 
@@ -95,7 +95,7 @@ And also a convention for kind ranges that allow for easier experimentation and
 - for kind `n` such that `1000 <= n < 10000 || 4 <= n < 45 || n == 1 || n == 2`, events are **regular**, which means they're all expected to be stored by relays.
 - for kind `n` such that `10000 <= n < 20000 || n == 0 || n == 3`, events are **replaceable**, which means that, for each combination of `pubkey` and `kind`, only the latest event MUST be stored by relays, older versions MAY be discarded.
 - for kind `n` such that `20000 <= n < 30000`, events are **ephemeral**, which means they are not expected to be stored by relays.
-- for kind `n` such that `30000 <= n < 40000`, events are **parameterized replaceable**, which means that, for each combination of `pubkey`, `kind` and the `d` tag's first value, only the latest event MUST be stored by relays, older versions MAY be discarded.
+- for kind `n` such that `30000 <= n < 40000`, events are **addressable** by their `kind`, `pubkey` and `d` tag value -- which means that, for each combination of `kind`, `pubkey` and the `d` tag value, only the latest event MUST be stored by relays, older versions MAY be discarded.
 
 In case of replaceable events with the same timestamp, the event with the lowest id (first in lexical order) should be retained, and the other discarded.
 
@@ -131,7 +131,7 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
 }
 ```
 
-Upon receiving a `REQ` message, the relay SHOULD query its internal database and return events that match the filter, then store that filter and send again all future events it receives to that same websocket until the websocket is closed. The `CLOSE` event is received with the same `<subscription_id>` or a new `REQ` is sent using the same `<subscription_id>`, in which case relay MUST overwrite the previous subscription.
+Upon receiving a `REQ` message, the relay SHOULD return events that match the filter. Any new events it receives SHOULD be sent to that same websocket until the connection is closed, a `CLOSE` event is received with the same `<subscription_id>`, or a new `REQ` is sent using the same `<subscription_id>` (in which case a new subscription is created, replacing the old one).
 
 Filter attributes containing lists (`ids`, `authors`, `kinds` and tag filters like `#e`) are JSON arrays with one or more values. At least one of the arrays' values must match the relevant field in an event for the condition to be considered a match. For scalar event attributes such as `authors` and `kind`, the attribute from the event must be contained in the filter list. In the case of tag attributes such as `#e`, for which an event may have multiple values, the event and filter condition values must have at least one item in common.
 
@@ -169,7 +169,6 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
   * `["OK", "b1a649ebe8...", false, "pow: difficulty 26 is less than 30"]`
   * `["OK", "b1a649ebe8...", false, "error: could not connect to the database"]`
 - `CLOSED` messages MUST be sent in response to a `REQ` when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a `CLOSE`. This message uses the same pattern of `OK` messages with the machine-readable prefix and human-readable message. Some examples:
-  * `["CLOSED", "sub1", "duplicate: sub1 already opened"]`
   * `["CLOSED", "sub1", "unsupported: filter contains unknown elements"]`
   * `["CLOSED", "sub1", "error: could not connect to the database"]`
   * `["CLOSED", "sub1", "error: shutting down idle subscription"]`

02.md

@@ -14,7 +14,7 @@ The `.content` is not used.
 
 For example:
 
-```json
+```jsonc
 {
   "kind": 3,
   "tags": [
@@ -23,7 +23,7 @@ For example:
     ["p", "612ae..e610f", "ws://carolrelay.com/ws", "carol"]
   ],
   "content": "",
-  ...other fields
+  // other fields...
 }
 ```
 

05.md

@@ -16,12 +16,12 @@ The result should be a JSON document object with a key `"names"` that should the
 
 If a client sees an event like this:
 
-```json
+```jsonc
 {
   "pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9",
   "kind": 0,
   "content": "{\"name\": \"bob\", \"nip05\": \"bob@example.com\"}"
-  ...
+  // other fields...
 }
 ```
 

09.md

@@ -2,7 +2,7 @@ NIP-09
 ======
 
 Event Deletion Request
---------------
+----------------------
 
 `draft` `optional`
 
@@ -12,7 +12,7 @@ The event's `content` field MAY contain a text note describing the reason for th
 
 For example:
 
-```
+```jsonc
 {
   "kind": 5,
   "pubkey": <32-bytes hex-encoded public key of the event creator>,
@@ -24,7 +24,7 @@ For example:
     ["k", "30023"]
   ],
   "content": "these posts were published by accident",
-  ...other fields
+  // other fields...
 }
 ```
 

10.md

@@ -2,8 +2,8 @@ NIP-10
 ======
 
 
-On "e" and "p" tags in Text Events (kind 1).
---------------------------------------------
+On "e" and "p" tags in Text Events (kind 1)
+-------------------------------------------
 
 `draft` `optional`
 
@@ -43,7 +43,7 @@ They are citing from this event.  `root-id` and `reply-id` are as above.
 Where:
 
  * `<event-id>` is the id of the event being referenced.
- * `<relay-url>` is the URL of a recommended relay associated with the reference. Clients SHOULD add a valid `<relay-URL>` field, but may instead leave it as `""`.
+ * `<relay-url>` is the URL of a recommended relay associated with the reference. Clients SHOULD add a valid `<relay-url>` field, but may instead leave it as `""`.
  * `<marker>` is optional and if present is one of `"reply"`, `"root"`, or `"mention"`.
  * `<pubkey>` is optional, SHOULD be the pubkey of the author of the referenced event
 

11.md

@@ -2,7 +2,7 @@ NIP-11
 ======
 
 Relay Information Document
----------------------------
+--------------------------
 
 `draft` `optional`
 
@@ -66,7 +66,7 @@ These are limitations imposed by the relay on clients. Your client
 should expect that requests which exceed these *practical* limitations
 are rejected or fail immediately.
 
-```json
+```jsonc
 {
   "limitation": {
     "max_message_length": 16384,
@@ -83,7 +83,7 @@ are rejected or fail immediately.
     "created_at_lower_limit": 31536000,
     "created_at_upper_limit": 3
   },
-  ...
+  // other fields...
 }
 ```
 
@@ -146,14 +146,15 @@ Retention times are given in seconds, with `null` indicating infinity.
 If zero is provided, this means the event will not be stored at
 all, and preferably an error will be provided when those are received.
 
-```json
+```jsonc
 {
   "retention": [
     {"kinds": [0, 1, [5, 7], [40, 49]], "time": 3600},
     {"kinds": [[40000, 49999]], "time": 100},
     {"kinds": [[30000, 39999]], "count": 1000},
     {"time": 3600, "count": 10000}
-  ]
+  ],
+  // other fields...
 }
 ```
 
@@ -172,7 +173,7 @@ There is no need to specify retention times for _ephemeral events_ since they ar
 ### Content Limitations
 
 Some relays may be governed by the arbitrary laws of a nation state. This
-may limit what content can be stored in cleartext on those relays. All
+may limit what content can be stored in clear-text on those relays. All
 clients are encouraged to use encryption to work around this limitation.
 
 It is not possible to describe the limitations of each country's laws
@@ -183,13 +184,13 @@ 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
+and/or select relays in more favorable zones. Exposing this
 flexibility is up to the client software.
 
-```json
+```jsonc
 {
   "relay_countries": [ "CA", "US" ],
-  ...
+  // other fields...
 }
 ```
 
@@ -208,12 +209,12 @@ local community. This would encourage users to follow the global
 feed on that relay, in addition to their usual individual follows.
 To support this goal, relays MAY specify some of the following values.
 
-```json
+```jsonc
 {
   "language_tags": ["en", "en-419"],
   "tags": ["sfw-only", "bitcoin-only", "anime"],
   "posting_policy": "https://example.com/posting-policy.html",
-  ...
+  // other fields...
 }
 ```
 
@@ -260,20 +261,22 @@ Relays that require payments may want to expose their fee schedules.
 
 A URL pointing to an image to be used as an icon for the relay. Recommended to be squared in shape.
 
-```json
+```jsonc
 {
   "icon": "https://nostr.build/i/53866b44135a27d624e99c6165cabd76ac8f72797209700acb189fce75021f47.jpg",
-  ...
+  // other fields...
 }
 ```
 
 ### Examples
 
 As of 2 May 2023 the following command provided these results:
 
+```bash
+$ curl -H "Accept: application/nostr+json" https://eden.nostr.land | jq
 ```
-~> curl -H "Accept: application/nostr+json" https://eden.nostr.land | jq
 
+```json
 {
   "description": "nostr.land family of relays (us-or-01)",
   "name": "nostr.land",
@@ -312,3 +315,4 @@ As of 2 May 2023 the following command provided these results:
     ]
   },
 }
+```

13.md

@@ -48,37 +48,30 @@ Validating
 Here is some reference C code for calculating the difficulty (aka number of leading zero bits) in a nostr event id:
 
 ```c
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-int countLeadingZeroes(const char *hex) {
-    int count = 0;
-
-    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;
-        }
-    }
+int zero_bits(unsigned char b)
+{
+        int n = 0;
 
-    return count;
-}
+        if (b == 0)
+                return 8;
 
-int main(int argc, char *argv[]) {
-    if (argc != 2) {
-        fprintf(stderr, "Usage: %s <hex_string>\n", argv[0]);
-        return 1;
-    }
+        while (b >>= 1)
+                n++;
 
-    const char *hex_string = argv[1];
-    int result = countLeadingZeroes(hex_string);
-    printf("Leading zeroes in hex string %s: %d\n", hex_string, result);
+        return 7-n;
+}
 
-    return 0;
+/* 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;
 }
 ```
 

15.md

@@ -73,10 +73,10 @@ Fields that are not self-explanatory:
 
 **Event Tags**
 
-```json
+```jsonc
 {
   "tags": [["d", <string, id of stall]],
-  ...
+  // other fields...
 }
 ```
  - the `d` tag is required, its value MUST be the same as the stall `id`.
@@ -124,12 +124,12 @@ Fields that are not self-explanatory:
 
 **Event Tags**
 
-```json
+```jsonc
   "tags": [
     ["d", <string, id of product],
     ["t", <string (optional), product category],
     ["t", <string (optional), product category],
-    ...
+    // other fields...
   ],
   ...
 ```
@@ -158,7 +158,7 @@ The below JSON goes in content of [NIP-04](04.md).
   "type": 0,
   "name": <string (optional), ???>,
   "address": <string (optional), for physical goods an address should be provided>,
-  "message": "<string (optional), message for merchant>,
+  "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>,
@@ -237,7 +237,7 @@ Create a customized user experience using the `naddr` from [NIP-19](19.md#sharea
 
 **Event Content**
 
-```json
+```jsonc
 {
   "name": <string (optional), market name>,
   "about": <string (optional), market description>,
@@ -248,7 +248,7 @@ Create a customized user experience using the `naddr` from [NIP-19](19.md#sharea
     "darkMode": <bool, true/false>
   },
   "merchants": [array of pubkeys (optional)],
-  ...
+  // other fields...
 }
 ```
 
@@ -290,10 +290,11 @@ This event leverages naddr to enable comprehensive customization and sharing of
 
 ### Event `1021`: Bid
 
-```json
+```jsonc
 {
     "content": <int, amount of sats>,
     "tags": [["e", <event ID of the auction to bid on>]],
+    // other fields...
 }
 ```
 
@@ -335,4 +336,4 @@ Customer support is handled over whatever communication method was specified. If
 
 ## Additional
 
-Standard data models can be found <a href="https://raw.githubusercontent.com/lnbits/nostrmarket/main/models.py">here</a>
+Standard data models can be found [here](https://raw.githubusercontent.com/lnbits/nostrmarket/main/models.py)