recommend using "k" tag always.

01.md

@@ -78,8 +78,8 @@ 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>, <32-bytes lowercase hex of the author's pubkey, 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 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 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>]` (note: include the trailing colon)
+    - 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. Only the first value in any given tag is indexed.
 

17.md

@@ -21,7 +21,7 @@ Kind `14` is a chat message. `p` tags identify one or more receivers of the mess
   "tags": [
     ["p", "<receiver-1-pubkey>", "<relay-url>"],
     ["p", "<receiver-2-pubkey>", "<relay-url>"],
-    ["e", "<kind-14-id>", "<relay-url>"] // if this is a reply
+    ["e", "<kind-14-id>", "<relay-url>", "reply"] // if this is a reply
     ["subject", "<conversation-title>"],
     // rest of tags...
   ],
@@ -31,13 +31,7 @@ Kind `14` is a chat message. `p` tags identify one or more receivers of the mess
 
 `.content` MUST be plain text. Fields `id` and `created_at` are required.
 
-An `e` tag denotes the direct parent message this post is replying to. 
+Tags that mention, quote and assemble threading structures MUST follow [NIP-10](10.md).
-
-`q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
-
-```json
-["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
-```
 
 Kind `14`s MUST never be signed. If it is signed, the message might leak to relays and become **fully public**.
 
@@ -57,7 +51,7 @@ Kind `14`s MUST never be signed. If it is signed, the message might leak to rela
     ["file-type", "<file-mime-type>"],
     ["encryption-algorithm", "<encryption-algorithm>"],
     ["decryption-key", "<decryption-key>"],
-    ["decryption-nonce", "<decryption-nonce>"],
+    ["decryptiion-nonce", "<decryption-nonce>"],
     ["x", "<the SHA-256 hexencoded string of the file>"],
     // rest of tags...
   ],
@@ -74,16 +68,16 @@ Kind 15 is used for sending encrypted file event messages:
 - `content`: The URL of the file (`<file-url>`).
 - `x` containing the SHA-256 hexencoded string of the file.
 - `size` (optional) size of file in bytes
-- `dim` (optional) size of the file in pixels in the form `<width>x<height>`
+- `dim` (optional) size of file in pixels in the form `<width>x<height>`
-- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the client is loading the file
+- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the file is being loaded by the client
-- `thumb` (optional) URL of thumbnail with same aspect ratio (encrypted with the same key, nonce)
+- `thumb` (optional) url of thumbnail with same aspect ratio
 - `fallback` (optional) zero or more fallback file sources in case `url` fails
 
 Just like kind 14, kind `15`s MUST never be signed.
 
 ## Chat Rooms
 
-The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with a clean message history.
+The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with clean message history.
 
 Clients SHOULD render messages of the same room in a continuous thread.
 
@@ -91,7 +85,7 @@ An optional `subject` tag defines the current name/topic of the conversation. An
 
 ## Encrypting
 
-Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat messages must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
+Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat message must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
 
 ```jsonc
 {
@@ -173,7 +167,7 @@ The main limitation of this approach is having to send a separate encrypted even
 
 Clients implementing this NIP should by default only connect to the set of relays found in their `kind:10050` list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast.
 
-When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set.
+When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there, but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set.
 
 ## Examples
 

23.md

@@ -60,7 +60,3 @@ References to other Nostr notes, articles or profiles must be made according to
   "id": "..."
 }
 ```
-
-### Replies & Comments
-
-Replies to `kind 30023` MUST use [NIP-22](./22.md) `kind 1111` comments. 

24.md

@@ -17,7 +17,6 @@ These are extra fields not specified in NIP-01 that may be present in the string
   - `website`: a web URL related in any way to the event author.
   - `banner`: an URL to a wide (~1024x768) picture to be optionally displayed in the background of a profile screen.
   - `bot`: a boolean to clarify that the content is entirely or partially the result of automation, such as with chatbots or newsfeeds.
-  - `birthday`: an object representing the author's birth date. The format is { "year": number, "month": number, "day": number }. Each field MAY be omitted.
 
 ### Deprecated fields
 

34.md

@@ -125,7 +125,24 @@ Issues may have a `subject` tag, which clients can utilize to display a header.
 
 ## Replies
 
-Replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event should follow [NIP-22 comment](22.md).
+Replies are also Markdown text. The difference is that they MUST be issued as replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event. The threading of replies and patches should follow NIP-10 rules.
+
+```jsonc
+{
+  "kind": 1622,
+  "content": "<markdown text>",
+  "tags": [
+    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
+    ["e", "<issue-or-patch-id-hex>", "", "root"],
+
+    // other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
+    ["p", "<patch-author-pubkey-hex>", "", "mention"],
+    ["e", "<previous-reply-id-hex>", "", "reply"],
+    // rest of tags...
+  ],
+  // other fields...
+}
+```
 
 ## Status
 

45.md

@@ -29,51 +29,15 @@ In case a relay uses probabilistic counts, it MAY indicate it in the response wi
 
 Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST return a `CLOSED` message.
 
-## HyperLogLog
-
-Relays may return an HyperLogLog value together with the count, hex-encoded.
-
-```
-["COUNT", <subscription_id>, {"count": <integer>, "hll": "<hex>"}]
-```
-
-This is so it enables merging results from multiple relays and yielding a reasonable estimate of reaction counts, comment counts and follower counts, while saving many millions of bytes of bandwidth for everybody.
-
-### Algorithm
-
-This section describes the steps a relay should take in order to return HLL values to clients.
-
-1. Upon receiving a filter, if it is eligible (see below) for HyperLogLog, compute the deterministic `offset` for that filter (see below);
-2. Initialize 256 registers to `0` for the HLL value;
-3. For all the events that are to be counted according to the filter, do this:
-    1. Read the byte at position `offset` of the event `pubkey`, its value will be the register index `ri`;
-    2. Count the number of leading zero bits starting at position `offset+1` of the event `pubkey` and add `1`;
-    3. Compare that with the value stored at register `ri`, if the new number is bigger, store it.
-
-That is all that has to be done on the relay side, and therefore the only part needed for interoperability.
-
-On the client side, these HLL values received from different relays can be merged (by simply going through all the registers in HLL values from each relay and picking the highest value for each register, regardless of the relay).
-
-And finally the absolute count can be estimated by running some methods I don't dare to describe here in English, it's better to check some implementation source code (also, there can be different ways of performing the estimation, with different quirks applied on top of the raw registers).
-
-### Filter eligibility and `offset` computation
-
-This NIP defines (for now) two filters eligible for HyperLogLog:
-
-- `{"#p": ["<pubkey>"], "kinds": [3]}`, i.e. a filter for `kind:3` events with a single `"p"` tag, which means the client is interested in knowing how many people "follow" the target `<pubkey>`. In this case the `offset` will be given by reading the character at the position `32` of the hex `<pubkey>` value as a base-16 number then adding `8` to it.
-- `{"#e": ["<id>"], "kinds": [7]}`, i.e. a filter for `kind:7` events with a single `"e"` tag, which means the client is interested in knowing how many people have reacted to the target event `<id>`. In this case the `offset` will be given by reading the character at the position `32` of the hex `<id>` value as a base-16 number then adding `8` to it.
-- `{"#E": ["<id>"], "kinds": [1111]}`, i.e. a filter for the total number of comments any specific root event has received. In this case the `offset` will be given by reading the character at the position `32` of the hex `<id>` value as a base-16 number then adding `8` to it.
-
-### Attack vectors
-
-One could mine a pubkey with a certain number of zero bits in the exact place where the HLL algorithm described above would look for them in order to artificially make its reaction or follow "count more" than others. For this to work a different pubkey would have to be created for each different target (event id, followed profile etc). This approach is not very different than creating tons of new pubkeys and using them all to send likes or follow someone in order to inflate their number of followers. The solution is the same in both cases: clients should not fetch these reaction counts from open relays that accept everything, they should base their counts on relays that perform some form of filtering that makes it more likely that only real humans are able to publish there and not bots or artificially-generated pubkeys.
-
-### `hll` encoding
-
-The value `hll` value must be the concatenation of the 256 registers, each being a uint8 value (i.e. a byte). Therefore `hll` will be a 512-character hex string.
-
 ## Examples
 
+### Followers count
+
+```
+["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
+["COUNT", <subscription_id>, {"count": 238}]
+```
+
 ### Count posts and reactions
 
 ```
@@ -81,7 +45,6 @@ The value `hll` value must be the concatenation of the 256 registers, each being
 ["COUNT", <subscription_id>, {"count": 5}]
 ```
 
-
 ### Count posts approximately
 
 ```
@@ -89,13 +52,6 @@ The value `hll` value must be the concatenation of the 256 registers, each being
 ["COUNT", <subscription_id>, {"count": 93412452, "approximate": true}]
 ```
 
-### Followers count with HyperLogLog
-
-```
-["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
-["COUNT", <subscription_id>, {"count": 16578, "hll": "0607070505060806050508060707070706090d080b0605090607070b07090606060b0705070709050807080805080407060906080707080507070805060509040a0b06060704060405070706080607050907070b08060808080b080607090a06060805060604070908050607060805050d05060906090809080807050e0705070507060907060606070708080b0807070708080706060609080705060604060409070a0808050a0506050b0810060a0908070709080b0a07050806060508060607080606080707050806080c0a0707070a080808050608080f070506070706070a0908090c080708080806090508060606090906060d07050708080405070708"}]
-```
-
 ### Relay refuses to count
 
 ```

55.md

@@ -484,8 +484,6 @@ If the user chose to always reject the event, signer application will return the
 
 # Usage for Web Applications
 
-You should consider using [NIP-46: Nostr Connect](46.md) for a better experience for web applications. When using this approach, the web app can't call the signer in the background, so the user will see a popup for every event you try to sign.
-
 Since web applications can't receive a result from the intent, you should add a modal to paste the signature or the event json or create a callback url.
 
 If you send the callback url parameter, Signer Application will send the result to the url.

65.md

@@ -63,8 +63,6 @@ This NIP allows Clients to connect directly with the most up-to-date relay set f
 
 6. Clients SHOULD deduplicate connections by normalizing relay URIs according to [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986#section-6).
 
-7. When publishing to a relay, clients SHOULD ensure the user's `kind 10002` is also available on that relay. Relays SHOULD accept and serve `kind 10002` notes for any pubkey whose notes they store. Relays MAY scrape the network for missing `kind 10002` events. The goal here is that for any note served from a relay the user can also request the author's relay selections as a way of bootstrapping further context discovery.
-
 ## Related articles
 - [Outbox model](https://mikedilger.com/gossip-model/)
 - [What is the Outbox Model?](https://habla.news/u/hodlbod@coracle.social/8YjqXm4SKY-TauwjOfLXS)

66.md

@@ -1,250 +0,0 @@
-# NIP-66: Relay Discovery and Liveness Monitoring
-
-`draft` `optional`
-
-You want to find relays. You may want to discover relays based on criteria that's up to date. You may even want to ensure that you have a complete dataset. You probably want to filter relays based on their reported liveness.
-
-In its purest form:
-
-```json
-{
-  "kind": 30166,
-  "created_at": 1722173222,  
-  "content": "{}",
-  "tags": [
-    [ "d", "wss://somerelay.abc/" ]
-  ],
-  "pubkey": "<pubkey>", 
-  "sig": "<signature>",
-  "id": "<eventid>"
-}
-```
-
-This event signals that the relay at `wss://somerelay.abc/` was reported "online" by `<pubkey>` at timestamp `1722173222`. This event **MAY** be extended upon to include more information.
-
-## Kinds
-`NIP-66` defines two (2) event kinds, `30166` and `10166`
-
-| kind  | name                       | description                                                                             |
-|-------|----------------------------|-----------------------------------------------------------------------------------------|
-| [30166](#k30166) | Relay Discovery      | An addressable event that is published by a monitor when a relay is online |
-| [10166](#k10166) | Relay Monitor Announcement | An RE that stores data that signals the intent of a pubkey to monitor relays and publish `30166` events at a regular _frequency_ |
-
-## Ontology
-- `Relay Operator`: someone who operates a relay 
-- `Monitor`: A pubkey that monitors relays and publishes `30166` events at the frequency specified in their `10166` event.
-- `Ad-hoc Monitor`: A pubkey that monitors relays and publishes `30166` events at an irregular frequency.
-- `Monitor Service`: A group or individual that monitors relays using one or more `Monitors`.
-- `Check`: a specific data point that is tested or aggregated by a monitor.
-
-## `30166`: "Relay Discovery" <a id="k30166"></a>
-
-### Summary
-`30166` is a `NIP-33` addressable event, referred to as a "Relay Discovery" event. These events are optimized with a small footprint for protocol-level relay Discovery.
-
-### Purpose 
-Discovery of relays over nostr. 
-
-### Schema 
-
-#### Content 
-`30166` content fields **SHOULD** include the stringified JSON of the relay's NIP-11 informational document. This data **MAY** be provided for informational purposes only. 
-
-#### `created_at`
-The `created_at` field in a NIP-66 event should reflect the time when the relay liveness (and potentially other data points) was checked.
-
-#### `tags`
-
-##### Meta Tags (unindexed)
-- `rtt-open` The relay's open **round-trip time** in milliseconds.
-- `rtt-read` The relay's read **round-trip time** in milliseconds.
-- `rtt-write` The relay's write **round-trip time** in milliseconds.
-
-_Other `rtt` values **MAY** be present. This NIP should be updated if there is value found in more `rtt` values._
-
-##### Single Letter Tags (indexed)
-- `d` The relay URL/URI. The `#d` tag **must** be included in the `event.tags[]` array. Index position `1` **must** be the relay websocket URL/URI. If a URL it **SHOULD** be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6). For relays not accessible via conventional means but rather by an npub/pubkey, an npub/pubkey **MAY** be used in place of a URL.
-  ```json
-  [ "d", "wss://somerelay.abc/"]
-  ```
-
-- `n`: Network
-  ```json
-  [ "n", "clearnet" ]
-  ```
-
-- `T`: Relay Type. Enumerated [relay type](https://github.com/nostr-protocol/nips/issues/1282) formatted as `PascalCase`
-  ```json
-  ["T", "PrivateInbox" ]
-  ```
-
-- `N`: Supported Nips _From NIP-11 "Informational Document" `nip11.supported_nips[]`_
-  ```json
-  [ "N", "42" ]
-  ```
-
-- `R`: Requirements _NIP-11 "Informational Document" `nip11.limitations.payment_required`, `nip11.limitations.auth_required` and/or any other boolean value within `nip11.limitations[]` that is added in the future_
-  ```json
-  [ "R", "payment" ],
-  [ "R", "auth" ],
-  ```
-  Since the nostr protocol does not currently support filtering on whether an indexed tag **is** or **is not** set, to make "public" and "no auth" relays discoverable requires a `!` flag
-
-  ```json
-  [ "R", "!payment" ], //no payment required, is public
-  [ "R", "!auth" ], //no authentication required
-  ```
-
-- `t`: "Topics" _From NIP-11 "Informational Document" `nip11.tags[]`_
-  ```json
-  [ "t", "nsfw" ]
-  ```
-
-- `k`: Accepted/Blocked Kinds [`NIP-22`]
-  ```json
-  [ "k", "0" ],
-  [ "k", "3" ],
-  [ "k", "10002" ]
-  ```
-
-  or for blocked kinds
-
-  ```json
-  [ "k", "!0" ]
-  [ "k", "!3" ],
-  [ "k", "!10002" ]
-  ```
-
-- `g`: `NIP-52` `g` tags (geohash)
-  ```json
-  [ "g", "9r1652whz" ]
-  ```
-
-- `30166` **MAY** be extended with global tags defined by other NIPs that do no collide with locally defined indices, including but not limited to: `p`, `t`, `e`, `a`, `i` and `l/L`. 
-
-#### Robust Example of a `30166` Event
-_Relay was online, and you can filter on a number of different tags_
-```json
-{
-  "id": "<eventid>",
-  "pubkey": "<monitor's pubkey>",
-  "created_at": "<created_at  [some recent date ...]>",
-  "signature": "<signature>",
-  "content": "{}",
-  "kind": 30166,
-  "tags": [  
-    ["d","wss://some.relay/"],
-    ["n", "clearnet"],
-    ["N", "40"],
-    ["N", "33"],
-    ["R", "!payment"],
-    ["R", "auth"],
-    ["g", "ww8p1r4t8"],
-    ["p", "somehexkey..."],
-    ["l", "en", "ISO-639-1"],
-    ["t", "nsfw" ],
-    ["rtt-open", 234 ]
-  ]
-} 
-```
-
-## `10166`: "Relay Monitor Announcement" Events <a id="k10166"></a>
-
-### Summary 
-`10166` is a replacable event herein referred to as "Relay Monitor Announcement" events. These events contain information about a publisher's intent to monitor and publish data as `30166` events. This event is optional and is intended for monitors who intend to provide monitoring services at a regular and predictable frequency.
-
-### Purpose 
-To provide a directory of monitors, their intent to publish, their criteria and parameters of monitoring activities. Absence of this event implies the monitor is ad-hoc and does not publish events at a predictable frequency, and relies on mechanisms to infer data integrity, such as web-of-trust.
-
-### Schema
-
-#### Standard Tags
-
-- `frequency` The frequency **in seconds** at which the monitor publishes events. A string-integer at index `1` represents the expected frequency the monitor will publish `30166` events. There should only be `1` frequency per monitor. 
-
-  ```json
-  [ "frequency", "3600" ]
-  ```
-
-- `timeout` (optional) The timeout values for various checks conducted by a monitor. Index `1` is the monitor's timeout in milliseconds. Index `2` describes what test the timeout is used for. If no index `2` is provided, it is inferred that the timeout provided applies to all tests. These values can assist relay operators in understanding data signaled by the monitor in _Relay Discovery Events_. 
-  ```json
-  [ "timeout", "2000", "open" ],
-  [ "timeout", "2000", "read" ],
-  [ "timeout", "3000", "write" ],
-  [ "timeout", "2000", "nip11" ],
-  [ "timeout", "4000", "ssl" ]
-  ```
-
-#### Indexed Tags
-- `c`  "Checks" **SHOULD** be a lowercase string describing the check(s) conducted by a monitor. Due to the rapidly evolving nature of relays, enumeration is organic and not strictly defined. But examples of some checks could be websocket `open/read/write/auth`, `nip11` checks, `dns` and `geo` checks, and and any other checks the monitor may deem useful.. Other checks **MAY** be included. New types of checks **SHOULD** be added to this NIP as they are needed.
-  ```json
-  [ "c", "ws" ],
-  [ "c", "nip11" ],
-  [ "c", "dns" ],
-  [ "c", "geo" ],
-  [ "c", "ssl" ],
-  ```
-
-- `g`: `NIP-52` `g` tags (geohash)
-  ```json
-  [ "g", "9r1652whz" ]
-  ```
-
-- Any other globally defined indexable tags **MAY** be included as found necessary.
-
-### Other Requirements
-Monitors **SHOULD** have the following 
-- A published `0` (NIP-1) event
-- A published `10002` (NIP-65) event that defines the relays the monitor publishes to.
-
-### Robust Example of a `10166` Event
-```json
-{
-  "id": "<eventid>",
-  "pubkey": "<monitor's pubkey>",
-  "created_at": "<created_at  [some recent date ...]>",
-  "signature": "<signature>",
-  "content": "",
-  "tags": [  
-
-    [ "timeout", "open", "5000"  ],
-    [ "timeout", "read", "3000"  ],
-    [ "timeout", "write", "3000" ],
-    [ "timeout", "nip11", "3000" ],
-
-    [ "frequency", "3600" ],
-
-    [ "c", "ws" ],
-    [ "c", "nip11" ],
-    [ "c", "ssl" ],
-    [ "c", "dns" ],
-    [ "c", "geo" ]
-
-    [ "g", "ww8p1r4t8" ]
-  ]
-} 
-```
-
-## Methodology 
-
-### Monitors
-1. A _Relay Monitor_ checks the liveness and potentially other attributes of a relay. 
-
-2. _Relay Monitor_ publishes a kind `30166` note when a relay it is monitoring is online. If the monitor has a `10166` event, events should be published at the frequency defined in their `10166` note. 
-
-_Any pubkey that publishes `30166` events **SHOULD** at a minimum be checking that the relay is available by websocket and behaves like a relay_
-
-### Clients
-1. In most cases, a client **SHOULD** filter on `30166` events using either a statically or dynamically defined monitor's `pubkey` and a `created_at` value respective of the monitor's published `frequency`. If the monitor has no stated frequency, other mechanisms should be employed to determine data integrity.
-
-2. _Relay Liveness_ is subjectively determined by the client, starting with the `frequency` value of a monitor. 
-
-3. The liveness of a _Relay Monitor_ can be subjectively determined by detecting whether the _Relay Monitor_ has published events with respect to `frequency` value of any particular monitor.
-
-4. The reliability and trustworthiness of a _Relay Monitor_ could be established via web-of-trust, reviews or similar mechanisms. 
-
-## Risk Mitigation
-
-- When a client implements `NIP-66` events, the client should have a fallback if `NIP-66` events cannot be located.
-
-- A `Monitor` or `Ad-hoc Monitor` may publish erroneous `30166` events, intentionally or otherwise. Therefor, it's important to program defensively to limit the impact of such events. This can be achieved with web-of-trust, reviews, fallbacks and/or data-aggregation for example.

73.md

@@ -9,40 +9,26 @@ External Content IDs
 There are certain established global content identifiers such as [Book ISBNs](https://en.wikipedia.org/wiki/ISBN), [Podcast GUIDs](https://podcastnamespace.org/tag/guid), and [Movie ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number) that are useful to reference in nostr events so that clients can query all the events assosiated with these ids.
 
 
-`i` tags are used for referencing these external content ids, with `k` tags representing the external content id kind so that clients can query all the events for a specific kind.
+`i` tags are used for referencing these external content ids, with `k` tags representing the external content id kind so that clients can query all the events for a specific kind. 
 
 ## Supported IDs
 
-| Type                   | `i` tag                                                    | `k` tag                  |
+| Type | `i` tag | `k` tag |
-| ---                    | ---                                                        | ---                      |
+|- | - | - |
-| URLs                   | "`<URL, normalized, no fragment>`"                         | "web"                    |
+| URLs | "`<URL, normalized, no fragment>`" | "`<scheme-host, normalized>`" |
-| Books                  | "isbn:`<id, without hyphens>`"                             | "isbn"                   |
+| Hashtags | "#`<topic, lowercase>`" | "#" |
-| Geohashes              | "geo:`<geohash, lowercase>`"                               | "geo"                    |
+| Geohashes| "geo:`<geohash, lowercase>`" | "geo" |
-| Movies                 | "isan:`<id, without version part>`"                        | "isan"                   |
+| Books | "isbn:`<id, without hyphens>`" | "isbn" |
-| Papers                 | "doi:`<id, lowercase>`"                                    | "doi"                    |
+| Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
-| Hashtags               | "#`<topic, lowercase>`"                                    | "#"                      |
+| Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
-| Podcast Feeds          | "podcast:guid:`<guid>`"                                    | "podcast:guid"           |
+| Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
-| Podcast Episodes       | "podcast:item:guid:`<guid>`"                               | "podcast:item:guid"      |
+| Movies | "isan:`<id, without version part>`" | "isan" |
-| Podcast Publishers     | "podcast:publisher:guid:`<guid>`"                          | "podcast:publisher:guid" |
+| Papers | "doi:`<id, lowercase>`" | "doi" |
-| Blockchain Transaction | "`<blockchain>`:[`<chainId>`:]tx:`<txid, hex, lowercase>`" | "`<blockchain>`:tx"      |
-| Blockchain Address     | "`<blockchain>`:[`<chainId>`:]address:`<address>`"         | "`<blockchain>`:address" |
 
 ---
 
 ## Examples
 
-
-### Webpages
-
-For the webpage "https://myblog.example.com/post/2012-03-27/hello-world" the "i" and "k" tags are:
-
-```jsonc
-[
-  ["i", "https://myblog.example.com/post/2012-03-27/hello-world"],
-  ["k", "web"]
-]
-```
-
 ### Books:
 
 - Book ISBN: `["i", "isbn:9780765382030"]` - https://isbnsearch.org/isbn/9780765382030
@@ -61,62 +47,6 @@ Book ISBNs MUST be referenced _**without hyphens**_ as many book search APIs ret
 
 Movie ISANs SHOULD be referenced  _**without the version part**_ as the versions / edits of movies are not relevant. More info on ISAN parts here -  https://support.isan.org/hc/en-us/articles/360002783131-Records-relations-and-hierarchies-in-the-ISAN-Registry
 
-### Blockchain
-
-`<blockchain>` can be any layer 1 chain (`bitcoin`, `ethereum`, `solana`, ...). If necessary (e.g. for ethereum), you can specify a `<chainId>`.
-
-#### Bitcoin
-
-```
-bitcoin:address:<bech32, lowercase | base58, case sensitive>
-bitcoin:tx:<txid, hex, lowercase>
-```
-
-E.g. https://blockstream.info/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d
-
-```jsonc
-[
-  ["i", "bitcoin:tx:a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d"],
-  ["k", "bitcoin:tx"]
-]
-```
-
-E.g. https://blockstream.info/address/1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx
-
-```jsonc
-[
-  ["i", "bitcoin:address:1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx"],
-  ["k", "bitcoin:address"]
-]
-```
-
-#### Ethereum (and other EVM chains)
-
-```
-ethereum:<chainId, integer>:tx:<txHash, hex, lowercase>
-ethereum:<chainId, integer>:address:<hex, lowercase>
-```
-
-E.g. https://etherscan.io/address/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
-
-```jsonc
-[
-  ["i", "ethereum:1:address:0xd8da6bf26964af9d7eed9e03e53415d37aa96045"],
-  ["k", "ethereum:address"]
-]
-```
-
-E.g. https://gnosisscan.io/tx/0x98f7812be496f97f80e2e98d66358d1fc733cf34176a8356d171ea7fbbe97ccd
-
-```jsonc
-[
-  ["i", "ethereum:100:tx:0x98f7812be496f97f80e2e98d66358d1fc733cf34176a8356d171ea7fbbe97ccd"],
-  ["k", "ethereum:tx"]
-]
-```
-
-
-
 ---
 
 ### Optional URL Hints
@@ -126,3 +56,5 @@ Each `i` tag MAY have a url hint as the second argument to redirect people to a
 `["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg]`
 
 `["i", "isan:0000-0000-401A-0000-7", https://www.imdb.com/title/tt0120737]`
+
+

C0.md

@@ -1,65 +0,0 @@
-# NIP-C0: Code Snippets
-
-`draft` `optional`
-
-## Abstract
-
-This NIP defines a new event kind for sharing and storing code snippets. Unlike regular text notes (`kind:1`), code snippets have specialized metadata like language, extension, and other code-specific attributes that enhance discoverability, syntax highlighting, and improved user experience.
-
-## Event Kind
-
-This NIP defines `kind:1337` as a code snippet event.
-
-The `.content` field contains the actual code snippet text.
-
-## Optional Tags
-
-- `l` - Programming language name (lowercase). Examples: "javascript", "python", "rust"
-- `name` - Name of the code snippet, commonly a filename. Examples: "hello-world.js", "quick-sort.py"
-- `extension` - File extension (without the dot). Examples: "js", "py", "rs"
-- `description` - Brief description of what the code does
-- `runtime` - Runtime or environment specification (e.g., "node v18.15.0", "python 3.11")
-- `license` - License under which the code is shared (e.g., "MIT", "GPL-3.0", "Apache-2.0")
-- `dep` - Dependency required for the code to run (can be repeated)
-- `repo` - Reference to a repository where this code originates
-
-## Format
-
-```json
-{
-  "id": "<32-bytes lowercase hex-encoded SHA-256 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": 1337,
-  "content": "function helloWorld() {\n  console.log('Hello, Nostr!');\n}\n\nhelloWorld();",
-  "tags": [
-    ["l", "javascript"],
-    ["extension", "js"],
-    ["name", "hello-world.js"],
-    ["description", "A basic JavaScript function that prints 'Hello, Nostr!' to the console"],
-    ["runtime", "node v18.15.0"],
-    ["license", "MIT"],
-    ["repo", "https://github.com/nostr-protocol/nostr"]
-  ],
-  "sig": "<64-bytes signature of the id>"
-}
-```
-
-## Client Behavior
-
-Clients that support this NIP SHOULD:
-
-1. Display code snippets with proper syntax highlighting based on the language.
-2. Allow copying the full code snippet with a single action.
-3. Render the code with appropriate formatting, preserving whitespace and indentation.
-4. Display the language and extension prominently.
-5. Provide "run" functionality for supported languages when possible.
-6. Display the description (if available) as part of the snippet presentation.
-
-Clients MAY provide additional functionality such as:
-
-1. Code editing capabilities
-2. Forking/modifying snippets
-3. Creating executable environments based on the runtime/dependencies
-4. Downloading the snippet as a file using the provided extension
-5. Sharing the snippet with attribution

README.md

@@ -80,7 +80,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-62: Request to Vanish](62.md)
 - [NIP-64: Chess (PGN)](64.md)
 - [NIP-65: Relay List Metadata](65.md)
-- [NIP-66: Relay Discovery and Liveness Monitoring](66.md)
 - [NIP-68: Picture-first feeds](68.md)
 - [NIP-69: Peer-to-peer Order events](69.md)
 - [NIP-70: Protected Events](70.md)
@@ -100,7 +99,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
 - [NIP-7D: Threads](7D.md)
-- [NIP-C0: Code Snippets](C0.md)
 - [NIP-C7: Chats](C7.md)
 
 ## Event Kinds
@@ -128,10 +126,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `20`          | Picture                         | [68](68.md)                            |
 | `21`          | Video Event                     | [71](71.md)                            |
 | `22`          | Short-form Portrait Video Event | [71](71.md)                            |
-| `30`          | internal reference              | [NKBIP-03]                             |
-| `31`          | external web reference          | [NKBIP-03]                            |
-| `32`          | hardcopy reference              | [NKBIP-03]                            |
-| `33`          | prompt reference                | [NKBIP-03]                            |
 | `40`          | Channel Creation                | [28](28.md)                            |
 | `41`          | Channel Metadata                | [28](28.md)                            |
 | `42`          | Channel Message                 | [28](28.md)                            |
@@ -149,10 +143,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1068`        | Poll                            | [88](88.md)                            |
 | `1111`        | Comment                         | [22](22.md)                            |
 | `1311`        | Live Chat Message               | [53](53.md)                            |
-| `1337`        | Code Snippet                    | [C0](C0.md)                            |
 | `1617`        | Patches                         | [34](34.md)                            |
 | `1621`        | Issues                          | [34](34.md)                            |
-| `1622`        | Git Replies (deprecated)        | [34](34.md)                            |
+| `1622`        | Replies                         | [34](34.md)                            |
 | `1630`-`1633` | Status                          | [34](34.md)                            |
 | `1971`        | Problem Tracker                 | [nostrocket][nostrocket]               |
 | `1984`        | Reporting                       | [56](56.md)                            |
@@ -192,7 +185,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10050`       | Relay list to receive DMs       | [51](51.md), [17](17.md)               |
 | `10063`       | User server list                | [Blossom][blossom]                     |
 | `10096`       | File storage server list        | [96](96.md)                            |
-| `10166`       | Relay Monitor Announcement      | [66](66.md)                            |
 | `13194`       | Wallet Info                     | [47](47.md)                            |
 | `17375`       | Cashu Wallet Event              | [60](60.md)                            |
 | `21000`       | Lightning Pub RPC               | [Lightning.Pub][lnpub]                 |
@@ -219,11 +211,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30023`       | Long-form Content               | [23](23.md)                            |
 | `30024`       | Draft Long-form Content         | [23](23.md)                            |
 | `30030`       | Emoji sets                      | [51](51.md)                            |
-| `30040`       | Curated Publication Index       | [NKBIP-01]                             |
+| `30040`       | Modular Article Header          | [NKBIP-01]                             |
-| `30041`       | Curated Publication Content     | [NKBIP-01]                             |
+| `30041`       | Modular Article Content         | [NKBIP-01]                             |
 | `30063`       | Release artifact sets           | [51](51.md)                            |
 | `30078`       | Application-specific Data       | [78](78.md)                            |
-| `30166`       | Relay Discovery                 | [66](66.md)                            |
 | `30267`       | App curation sets               | [51](51.md)                            |
 | `30311`       | Live Event                      | [53](53.md)                            |
 | `30315`       | User Statuses                   | [38](38.md)                            |
@@ -254,9 +245,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 [cornychat-slideset]: https://cornychat.com/datatypes#kind30388slideset
 [cornychat-linkset]: https://cornychat.com/datatypes#kind31388linkset
 [joinstr]: https://gitlab.com/1440000bytes/joinstr/-/blob/main/NIP.md
-[NKBIP-01]: https://wikistr.com/nkbip-01*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
+[NKBIP-01]: https://wikistr.com/nkbip-01
-[NKBIP-02]: https://wikistr.com/nkbip-02*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
+[NKBIP-02]: https://wikistr.com/nkbip-02
-[NKBIP-03]: https://wikistr.com/nkbip-03*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
 [blossom]: https://github.com/hzrd149/blossom
 [Tidal-nostr]: https://wikistr.com/tidal-nostr
 
@@ -300,7 +290,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `I`               | root external identity               | --                              | [22](22.md)                                        |
 | `k`               | kind                                 | --                              | [18](18.md), [25](25.md), [72](72.md), [73](73.md) |
 | `K`               | root scope                           | --                              | [22](22.md)                                        |
-| `l`               | label, label namespace, language name| --                              | [32](32.md), [C0](C0.md)                           |
+| `l`               | label, label namespace               | --                              | [32](32.md)                                        |
 | `L`               | label namespace                      | --                              | [32](32.md)                                        |
 | `m`               | MIME type                            | --                              | [94](94.md)                                        |
 | `p`               | pubkey (hex)                         | relay URL, petname              | [01](01.md), [02](02.md), [22](22.md)              |
@@ -323,20 +313,17 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `clone`           | git clone URL                        | --                              | [34](34.md)                                        |
 | `content-warning` | reason                               | --                              | [36](36.md)                                        |
 | `delegation`      | pubkey, conditions, delegation token | --                              | [26](26.md)                                        |
-| `dep`             | Required dependency                  | --                              | [C0](C0.md)                                        |
+| `description`     | description                          | --                              | [34](34.md), [57](57.md), [58](58.md)              |
-| `description`     | description                          | --                              | [34](34.md), [57](57.md), [58](58.md), [C0](C0.md) |
 | `emoji`           | shortcode, image URL                 | --                              | [30](30.md)                                        |
 | `encrypted`       | --                                   | --                              | [90](90.md)                                        |
-| `extension`       | File extension                       | --                              | [C0](C0.md)                                        |
 | `expiration`      | unix timestamp (string)              | --                              | [40](40.md)                                        |
 | `file`            | full path (string)                   | --                              | [35](35.md)                                        |
 | `goal`            | event id (hex)                       | relay URL                       | [75](75.md)                                        |
 | `image`           | image URL                            | dimensions in pixels            | [23](23.md), [52](52.md), [58](58.md)              |
 | `imeta`           | inline metadata                      | --                              | [92](92.md)                                        |
-| `license`         | License of the shared content        | --                              | [C0](C0.md)                                        |
 | `lnurl`           | `bech32` encoded `lnurl`             | --                              | [57](57.md)                                        |
 | `location`        | location string                      | --                              | [52](52.md), [99](99.md)                           |
-| `name`            | name                                 | --                              | [34](34.md), [58](58.md), [72](72.md), [C0](C0.md) |
+| `name`            | name                                 | --                              | [34](34.md), [58](58.md), [72](72.md)              |
 | `nonce`           | random                               | difficulty                      | [13](13.md)                                        |
 | `preimage`        | hash of `bolt11` invoice             | --                              | [57](57.md)                                        |
 | `price`           | price                                | currency, frequency             | [99](99.md)                                        |
@@ -344,8 +331,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `published_at`    | unix timestamp (string)              | --                              | [23](23.md)                                        |
 | `relay`           | relay url                            | --                              | [42](42.md), [17](17.md)                           |
 | `relays`          | relay list                           | --                              | [57](57.md)                                        |
-| `repo`            | Reference to the origin repository   | --                              | [C0](C0.md)                                        |
-| `runtime`         | Runtime or environment specification | --                              | [C0](C0.md)                                        |
 | `server`          | file storage server url              | --                              | [96](96.md)                                        |
 | `subject`         | subject                              | --                              | [14](14.md), [17](17.md), [34](34.md)              |
 | `summary`         | summary                              | --                              | [23](23.md), [52](52.md)                           |