minor update to k tag that provides support for blocked kinds.

66.md

@@ -5,6 +5,7 @@
 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
 {
   "sig": "<signature>",
@@ -21,8 +22,8 @@ In its purest form:
   ]
 }
 ```
-This event signals that the relay at `wss://eostagram.com/` was reported "online" by `<pubkey>` at timestamp `1722173222`. This event **MAY** be extended upon to include more information.
 
+This event signals that the relay at `wss://eostagram.com/` was reported "online" by `<pubkey>` at timestamp `1722173222`. This event **MAY** be extended upon to include more information.
 
 ## Kinds
 This NIP defines two (2) event kinds, `10166` and `30166`
@@ -34,8 +35,8 @@ This NIP defines two (2) event kinds, `10166` and `30166`
 
 ## Ontology
 - `Relay Operator`: someone who operates a relay 
-- `Monitor Service`: a group or individual that monitors the network
+- `Monitor Service`: a group or individual that monitors relays
-- `Monitor`: a piece of software that aggregates network data and publishes that data at a specified frequency.
+- `Monitor`: a piece of software that aggregates relay data and publishes that data at a specified frequency.
 - `Check`: a specific data point that is tested or aggregated by a monitor.
 
 ## `10166`: "Relay Monitor Announcement" Events <a id="k10166"></a>
@@ -159,7 +160,7 @@ _Other `rtt` values **MAY** be present. This NIP should be updated if there is v
 
 - `N`: Supported Nips _From NIP-11 "Informational Document" `nip11.supported_nips[]`_
   ```json
-  [ "N", "33" ]
+  [ "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_
@@ -170,7 +171,7 @@ _Other `rtt` values **MAY** be present. This NIP should be updated if there is v
   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" ], //is public
+  [ "R", "!payment" ], //no payment required, is public
   [ "R", "!auth" ], //no authentication required
   ```
 
@@ -179,13 +180,21 @@ _Other `rtt` values **MAY** be present. This NIP should be updated if there is v
   [ "t", "nsfw" ]
   ```
 
-- `k`: Accepted Kinds
+- `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" ]
@@ -233,32 +242,6 @@ _Relay Monitors that publish `30166` events **SHOULD** at a minimum be checking
 
 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 within the specified `frequency`.
+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. 
-
-## Use Cases
-1. **Geographic Relay Discovery**: Identify relays situated near a specific geographic location or within a particular country, facilitating localized network interactions.
-
-2. **NIP Support Filtering**: Search for relays based on their support for specific Nostr Implementation Possibilities (NIPs), ensuring compatibility with desired protocol features.
-
-3. **Accessibility Search**: Locate relays that are free to use
-
-4. **Real-Time Status Monitoring**: Utilize a status client to display up-to-date statuses of various relays, providing insights into their current operational state.
-
-5. **Relay Network Analysis**: Analyze connections and patterns between relays using their IP addresses, aiding in network topology understanding and security assessments.
-
-6. **Error Detection in Relay Listings**: Spot and rectify erroneous entries in relay lists.
-
-7. **Performance Benchmarking**: Compare relays based on performance metrics like round-trip times and uptime, aiding in the selection of the most efficient relays for specific needs.
-
-8. **Language and Content Filtering**: Identify relays catering to specific languages or content types, enabling users to engage in a more targeted and relevant social networking experience.
-
-## History 
-- _**draft1** implemented in `January 2023` and proposed `February 2023`. "Too many one-letter indexable tags"_
-- _**draft2** experimented with `March 2023` "Everything should be expirable"_
-- _**draft3** experimented, never proposed_ 
-- _**draft4** experimented, never proposed_ 
-- _**draft5** proposed `December 2023`, "Needs to be indexed"_
-- _**draft6** proposed `February 2024`, "Just use one-letter indexable tags" (lol) and split Discovery and parse cases._
-- _**draft7** proposed `July 2024`, remove Relay Meta, offload case onto existing nips._