remove it from nip50 example too.

Co-authored-by: dskvr <dskvr@users.noreply.github.com>

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 a normal replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <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)
 
 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.
 
@@ -113,7 +113,7 @@ Relays expose a websocket endpoint to which clients can connect. Clients SHOULD
 Clients can send 3 types of messages, which must be JSON arrays, according to the following patterns:
 
   * `["EVENT", <event JSON as defined above>]`, used to publish events.
-  * `["REQ", <subscription_id>, <filters1>, <filters2>, ...]`, used to request events and subscribe to new updates.
+  * `["REQ", <subscription_id>, <filter>]`, used to request events and subscribe to new updates.
   * `["CLOSE", <subscription_id>]`, used to stop previous subscriptions.
 
 `<subscription_id>` is an arbitrary, non-empty string of max length 64 chars. It represents a subscription per connection. Relays MUST manage `<subscription_id>`s independently for each WebSocket connection. `<subscription_id>`s are not guaranteed to be globally unique.
@@ -142,8 +142,6 @@ The `since` and `until` properties can be used to specify the time range of even
 
 All conditions of a filter that are specified must match for an event for it to pass the filter, i.e., multiple conditions are interpreted as `&&` conditions.
 
-A `REQ` message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions.
-
 The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data.
 
 ### From relay to client: sending events and notices

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>", "reply"] // if this is a reply
+    ["e", "<kind-14-id>", "<relay-url>"] // if this is a reply
     ["subject", "<conversation-title>"],
     // rest of tags...
   ],
@@ -31,7 +31,13 @@ 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.
 
-Tags that mention, quote and assemble threading structures MUST follow [NIP-10](10.md).
+An `e` tag denotes the direct parent message this post is replying to. 
+
+`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**.
 
@@ -51,7 +57,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>"],
-    ["decryptiion-nonce", "<decryption-nonce>"],
+    ["decryption-nonce", "<decryption-nonce>"],
     ["x", "<the SHA-256 hexencoded string of the file>"],
     // rest of tags...
   ],
@@ -68,16 +74,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 file in pixels in the form `<width>x<height>`
-- `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
+- `dim` (optional) size of the 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
+- `thumb` (optional) URL of thumbnail with same aspect ratio (encrypted with the same key, nonce)
 - `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 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 a clean message history.
 
 Clients SHOULD render messages of the same room in a continuous thread.
 
@@ -85,7 +91,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 message 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 messages must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually.
 
 ```jsonc
 {
@@ -167,7 +173,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,3 +60,7 @@ 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. 

25.md

@@ -25,26 +25,21 @@ consider it a "+".
 Tags
 ----
 
-The reaction event SHOULD include `e` and `p` tags from the note the user is reacting to (and optionally `a` tags if the target is a replaceable event). This allows users to be notified of reactions to posts they were mentioned in. Including the `e` tags enables clients to pull all the reactions associated with individual posts or all the posts in a thread. `a` tags enables clients to seek reactions for all versions of a replaceable event.
+There MUST be always an `e` tag set to the `id` of the event that is being reacted to. The `e` tag SHOULD include a relay hint pointing to a relay where the event being reacted to can be found. If a client decides to include other `e`, which not recommended, the target event `id` should be last of the `e` tags.
 
-The last `e` tag MUST be the `id` of the note that is being reacted to.
+The SHOULD be a `p` tag set to the `pubkey` of the event being reacted to. If a client decides to include other `p` tags, which not recommended, the target event `pubkey` should be last the `p` tags.
 
-The last `p` tag MUST be the `pubkey` of the event being reacted to.
+If the event being reacted to is an addressable event, an `a` SHOULD be included together with the `e` tag, it must be set to the coordinates (`kind:pubkey:d-tag`) of the event being reacted to.
 
-The `a` tag MUST contain the coordinates (`kind:pubkey:d-tag`) of the replaceable being reacted to.
+The reaction SHOULD include a `k` tag with the stringified kind number of the reacted event as its value.
 
-The reaction event MAY include a `k` tag with the stringified kind number of the reacted event as its value.
-
-Example code
+**Example code**
 
 ```swift
 func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> NostrEvent {
-    var tags: [[String]] = liked.tags.filter {
-    	tag in tag.count >= 2 && (tag[0] == "e" || tag[0] == "p")
-    }
-    tags.append(["e", liked.id])
+    tags.append(["e", liked.id, liked.source_relays.first ?? ""])
     tags.append(["p", liked.pubkey])
-    tags.append(["k", liked.kind])
+    tags.append(["k", String(liked.kind)])
     let ev = NostrEvent(content: "+", pubkey: pubkey, kind: 7, tags: tags)
     ev.calculate_id()
     ev.sign(privkey: privkey)

27.md

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

34.md

@@ -22,9 +22,10 @@ Git repositories are hosted in Git-enabled servers, but their existence can be a
     ["description", "brief human-readable project description>"],
     ["web", "<url for browsing>", ...], // a webpage url, if the git server being used provides such a thing
     ["clone", "<url for git-cloning>", ...], // a url to be given to `git clone` so anyone can clone it
-    ["relays", "<relay-url>", ...] // relays that this repository will monitor for patches and issues
-    ["r", "<earliest-unique-commit-id>", "euc"]
-    ["maintainers", "<other-recognized-maintainer>", ...]
+    ["relays", "<relay-url>", ...], // relays that this repository will monitor for patches and issues
+    ["r", "<earliest-unique-commit-id>", "euc"],
+    ["maintainers", "<other-recognized-maintainer>", ...],
+    ["t", "<arbitrary string>"], // hashtags labelling the repository
   ]
 }
 ```

50.md

@@ -8,11 +8,11 @@ Search Capability
 
 ## Abstract
 
-Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids. 
-Specifics of the search algorithms will differ between event kinds, this NIP only describes a general 
+Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids.
+Specifics of the search algorithms will differ between event kinds, this NIP only describes a general
 extensible framework for performing such queries.
 
-## `search` filter field 
+## `search` filter field
 
 A new `search` field is introduced for `REQ` messages from clients:
 ```jsonc
@@ -21,23 +21,23 @@ A new `search` field is introduced for `REQ` messages from clients:
   "search": <string>
 }
 ```
-`search` field is a string describing a query in a human-readable form, i.e. "best nostr apps". 
-Relays SHOULD interpret the query to the best of their ability and return events that match it. 
+`search` field is a string describing a query in a human-readable form, i.e. "best nostr apps".
+Relays SHOULD interpret the query to the best of their ability and return events that match it.
 Relays SHOULD perform matching against `content` event field, and MAY perform
-matching against other fields if that makes sense in the context of a specific kind. 
+matching against other fields if that makes sense in the context of a specific kind.
 
 Results SHOULD be returned in descending order by quality of search result (as defined by the implementation),
 not by the usual `.created_at`. The `limit` filter SHOULD be applied after sorting by matching score.
-A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore 
+A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore
 extensions they don't support.
 
-Clients may specify several search filters, i.e. `["REQ", "", { "search": "orange" }, { "kinds": [1, 2], "search": "purple" }]`. Clients may 
+Clients may specify several search filters, i.e. `["REQ", "_", {"kinds": [1], "search": "purple"}]`. Clients may
 include `kinds`, `ids` and other filter field to restrict the search results to particular event kinds.
 
-Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search` 
+Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search`
 filter queries to any relay, if they are prepared to filter out extraneous responses from relays that do not support this NIP.
 
-Clients SHOULD query several relays supporting this NIP to compensate for potentially different 
+Clients SHOULD query several relays supporting this NIP to compensate for potentially different
 implementation details between relays.
 
 Clients MAY verify that events returned by a relay match the specified query in a way that suits the

53.md

@@ -63,7 +63,7 @@ This feature is important to avoid malicious event owners adding large account h
 
 ### Live Chat Message
 
-Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity with a `root` marker. Other Kind-1 tags such as `reply` and `mention` can also be used.
+Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity. An `e` tag denotes the direct parent message this post is replying to. 
 
 ```jsonc
 {
@@ -76,6 +76,12 @@ Event `kind:1311` is live chat's channel message. Clients MUST include the `a` t
 }
 ```
 
+`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>"]
+```
+
 Hosts may choose to pin one or more live chat messages by updating the `pinned` tags in the live event kind `30311`.
 
 ## Use Cases

55.md

@@ -484,6 +484,8 @@ 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.

62.md

@@ -0,0 +1,61 @@
+NIP-62
+======
+
+Request to Vanish
+-----------------
+
+`draft` `optional`
+
+This NIP offers a Nostr-native way to request a complete reset of a key's fingerprint on the web. This procedure is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database. 
+
+## Request to Vanish from Relay
+
+Kind `62` requests a specific relay to delete everything, including [NIP-09](09.md) Deletion Events, from the `.pubkey` until its `.created_at`. 
+
+```jsonc
+{
+  "kind": 62,
+  "pubkey": <32-byte hex-encoded public key of the event creator>,
+  "tags": [
+    ["relay", "<relay url>"]
+  ],
+  "content": "<reason or note>",
+  //...other fields
+}
+```
+
+The tag list MUST include at least one `relay` value. 
+
+Content MAY include a reason or a legal notice to the relay operator. 
+
+Relays MUST fully delete any events from the `.pubkey` if their service URL is tagged in the event. 
+
+Relays SHOULD delete all [NIP-59](59.md) Gift Wraps that p-tagged the `.pubkey` if their service URL is tagged in the event, deleting all DMs to the pubkey.
+
+Relays MUST ensure the deleted events cannot be re-broadcasted into the relay. 
+
+Relays MAY store the signed request to vanish for bookkeeping.
+
+Paid relays or relays that restrict who can post MUST also follow the request to vanish regardless of the user's status. 
+
+Publishing a deletion request event (Kind `5`) against a request to vanish has no effect. Clients and relays are not obliged to support "unrequest vanish" functionality.
+
+Clients SHOULD send this event to the target relays only. 
+
+## Global Request to Vanish
+
+To request ALL relays to delete everything, the event MUST include a `relay` tag with the value `ALL_RELAYS` in uppercase. 
+
+```jsonc
+{
+  "kind": 62,
+  "pubkey": <32-byte hex-encoded public key of the event creator>,
+  "tags": [
+    ["relay", "ALL_RELAYS"]
+  ],
+  "content": "<reason>",
+  //...other fields
+}
+```
+
+Clients SHOULD broadcast this event to as many relays as possible. 

66.md

@@ -0,0 +1,250 @@
+# 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,26 +9,37 @@ 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 |
-|- | - | - |
-| URLs | "`<URL, normalized, no fragment>`" | "`<scheme-host, normalized>`" |
-| 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" |
-| Movies | "isan:`<id, without version part>`" | "isan" |
-| Papers | "doi:`<id, lowercase>`" | "doi" |
+| Type               | `i` tag                             | `k` tag                  |
+| ---                | ---                                 | ---                      |
+| URLs               | "`<URL, normalized, no fragment>`"  | "web"                    |
+| 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" |
+| Movies             | "isan:`<id, without version part>`" | "isan"                   |
+| 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
@@ -56,5 +67,3 @@ 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]`
-
-

BREAKING.md

@@ -5,6 +5,8 @@ reverse chronological order.
 
 | Date        | Commit    | NIP      | Change |
 | ----------- | --------- | -------- | ------ |
+| 2025-02-14  | [81908b6e](https://github.com/nostr-protocol/nips/commit/81908b6e) | [07](07.md), [46](46.md), [55](55.md) | `getRelays` and `get_relays` were removed |
+| 2025-02-07  | [0023ca81](https://github.com/nostr-protocol/nips/commit/0023ca81) | [10](10.md) | `"mention"` marker was removed |
 | 2025-01-31  | [6a4b125a](https://github.com/nostr-protocol/nips/commit/6a4b125a) | [71](71.md) | video events were changed to regular |
 | 2024-12-05  | [6d16019e](https://github.com/nostr-protocol/nips/commit/6d16019e) | [46](46.md) | message encryption was changed to NIP-44 |
 | 2024-11-12  | [2838e3bd](https://github.com/nostr-protocol/nips/commit/2838e3bd) | [29](29.md) | `kind: 12` and `kind: 10` were removed (use `kind: 1111` instead) |

README.md

@@ -77,8 +77,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-59: Gift Wrap](59.md)
 - [NIP-60: Cashu Wallet](60.md)
 - [NIP-61: Nutzaps](61.md)
+- [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)
@@ -125,11 +127,16 @@ 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)                            |
 | `43`          | Channel Hide Message            | [28](28.md)                            |
 | `44`          | Channel Mute User               | [28](28.md)                            |
+| `62`          | Request to Vanish               | [62](62.md)                            |
 | `64`          | Chess (PGN)                     | [64](64.md)                            |
 | `818`         | Merge Requests                  | [54](54.md)                            |
 | `1018`        | Poll Response                   | [88](88.md)                            |
@@ -183,6 +190,7 @@ 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]                 |
@@ -209,10 +217,11 @@ 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`       | Modular Article Header          | [NKBIP-01]                             |
-| `30041`       | Modular Article Content         | [NKBIP-01]                             |
+| `30040`       | Curated Publication Index       | [NKBIP-01]                             |
+| `30041`       | Curated Publication 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)                            |
@@ -243,8 +252,9 @@ 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
-[NKBIP-02]: https://wikistr.com/nkbip-02
+[NKBIP-01]: https://wikistr.com/nkbip-01*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
+[NKBIP-02]: https://wikistr.com/nkbip-02*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
+[NKBIP-03]: https://wikistr.com/nkbip-03*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
 [blossom]: https://github.com/hzrd149/blossom
 [Tidal-nostr]: https://wikistr.com/tidal-nostr
 
@@ -299,7 +309,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `s`               | status                               | --                              | [69](69.md)                                        |
 | `t`               | hashtag                              | --                              | [24](24.md), [34](34.md), [35](35.md)              |
 | `u`               | url                                  | --                              | [61](61.md), [98](98.md)                           |
-| `x`               | infohash                             | --                              | [35](35.md)                                        |
+| `x`               | hash                                 | --                              | [35](35.md), [56](56.md)                           |
 | `y`               | platform                             | --                              | [69](69.md)                                        |
 | `z`               | order number                         | --                              | [69](69.md)                                        |
 | `-`               | --                                   | --                              | [70](70.md)                                        |
@@ -374,4 +384,4 @@ All NIPs are public domain.
 
 <a align="center" href="https://github.com/nostr-protocol/nips/graphs/contributors">
   <img src="https://contrib.rocks/image?repo=nostr-protocol/nips" />
-</a>
+</a>