nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-23 00:45:53 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
dskvr 2024-08-29 15:18:39 +02:00
parent ceabeccb88
commit 42c5101834
1 changed files with 17 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
66.md
View File

@ -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. 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: In its purest form:
```json ```json
{ {
"sig": "<signature>", "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 ## Kinds
This NIP defines two (2) event kinds, `10166` and `30166` 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 ## Ontology
- `Relay Operator`: someone who operates a relay - `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. - `Check`: a specific data point that is tested or aggregated by a monitor.
## `10166`: "Relay Monitor Announcement" Events <a id="k10166"></a> ## `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[]`_ - `N`: Supported Nips _From NIP-11 "Informational Document" `nip11.supported_nips[]`_
```json ```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_ - `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 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 ```json
[ "R", "!payment" ], //is public [ "R", "!payment" ], //no payment required, is public
[ "R", "!auth" ], //no authentication required [ "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" ] [ "t", "nsfw" ]
``` ```
- `k`: Accepted Kinds - `k`: Accepted/Blocked Kinds [`NIP-22`]
```json ```json
[ "k", "0" ], [ "k", "0" ],
[ "k", "3" ], [ "k", "3" ],
[ "k", "10002" ] [ "k", "10002" ]
``` ```
or for blocked kinds
```json
[ "k", "!0" ]
[ "k", "!3" ],
[ "k", "!10002" ]
```
- `g`: `NIP-52` `g` tags (geohash) - `g`: `NIP-52` `g` tags (geohash)
```json ```json
[ "g", "9r1652whz" ] [ "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. 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. 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._