nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-09 22:09:06 -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.
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`: a piece of software that aggregates network data and publishes that data at a specified frequency.
- `Monitor Service`: a group or individual that monitors relays
- `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._
4. The reliability and trustworthiness of a _Relay Monitor_ could be established via web-of-trust, reviews or similar mechanisms.