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
 

29.md

@@ -153,7 +153,6 @@ When this event is not found, clients may still connect to the group, but treat
     ["name", "Pizza Lovers"],
     ["picture", "https://pizza.com/pizza.png"],
     ["about", "a group for people who love pizza"],
-    ["guidelines", "Rule #1: No pineapple"]
     ["public"], // or ["private"]
     ["open"] // or ["closed"]
   ]
@@ -161,7 +160,7 @@ When this event is not found, clients may still connect to the group, but treat
 }
 ```
 
-`name`, `picture`, `about`, and `guidelines` are basic metadata for the group for display purposes. `public` signals the group can be _read_ by anyone, while `private` signals that only AUTHed users can read. `open` signals that anyone can request to join and the request will be automatically granted, while `closed` signals that members must be pre-approved or that requests to join will be manually handled.
+`name`, `picture` and `about` are basic metadata for the group for display purposes. `public` signals the group can be _read_ by anyone, while `private` signals that only AUTHed users can read. `open` signals that anyone can request to join and the request will be automatically granted, while `closed` signals that members must be pre-approved or that requests to join will be manually handled.
 
 - *group admins* (`kind:39001`) (optional)
 

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
 

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

@@ -14,35 +14,21 @@ There are certain established global content identifiers such as [Book ISBNs](ht
 ## Supported IDs
 
 | 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"                   |
-| Geohashes              | "geo:`<geohash, lowercase>`"                               | "geo"                    |
-| Movies                 | "isan:`<id, without version part>`"                        | "isan"                   |
-| Papers                 | "doi:`<id, lowercase>`"                                    | "doi"                    |
 | Hashtags | "#`<topic, lowercase>`" | "#" |
+| Geohashes| "geo:`<geohash, lowercase>`" | "geo" |
+| Books | "isbn:`<id, without hyphens>`" | "isbn" |
 | Podcast Feeds | "podcast:guid:`<guid>`" | "podcast:guid" |
 | Podcast Episodes | "podcast:item:guid:`<guid>`" | "podcast:item:guid" |
 | Podcast Publishers | "podcast:publisher:guid:`<guid>`" | "podcast:publisher:guid" |
-| Blockchain Transaction | "`<blockchain>`:[`<chainId>`:]tx:`<txid, hex, lowercase>`" | "`<blockchain>`:tx"      |
+| Movies | "isan:`<id, without version part>`" | "isan" |
-| Blockchain Address     | "`<blockchain>`:[`<chainId>`:]address:`<address>`"         | "`<blockchain>`:address" |
+| Papers | "doi:`<id, lowercase>`" | "doi" |
 
 ---
 
 ## 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)                           |