highperfocused/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2025-03-25 17:21:52 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge f86ac200fe0ff41394f1902cdbbcc5eca8b2bdb3 into 0619f370bca3485bb9c5870bc2defa03c7c3d10e

Browse Source
This commit is contained in:
Sovereign Shadow 2025-03-21 03:08:07 -05:00 committed by GitHub
commit c9fce96a7d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
3 changed files with 38 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
01.md
View File

@ -144,7 +144,7 @@ All conditions of a filter that are specified must match for an event for it to
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.
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 the `provided` algo. and if some events have equile weight in their chosen order, they will be returned ordered by the `created_at`. 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

12
11.md
View File

@ -12,12 +12,14 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
```json
{
"type": <simple | aggregator>
"name": <string identifying relay>,
"description": <string with detailed information>,
"banner": <a link to an image (e.g. in .jpg, or .png format)>,
"icon": <a link to an icon (e.g. in .jpg, or .png format>,
"pubkey": <administrative contact pubkey>,
"contact": <administrative alternate contact>,
"algos": <a list of algos supported by the relay"
"supported_nips": <a list of NIP numbers supported by the relay>,
"software": <string identifying relay software URL>,
"version": <string version identifier>
@ -29,6 +31,10 @@ Any field may be omitted, and clients MUST ignore any additional fields they do
Field Descriptions
------------------
### Type
An aggregator relay gets events from more than 1 relay.
### Name
A relay may select a `name` for use in client software. This is a string, and SHOULD be less than 30 characters to avoid client truncation.
@ -62,6 +68,12 @@ Relay operators have no obligation to respond to direct messages.
An alternative contact may be listed under the `contact` field as well, with the same purpose as `pubkey`. Use of a Nostr public key and direct message SHOULD be preferred over this. Contents of this field SHOULD be a URI, using schemes such as `mailto` or `https` to provide users with a means of contact.
### Provided Algos
A relay SHOULD be honest about how the events are provided hence it SHOULD list all the algos it provides. Examples would include ["desc", "events in chronological order", "created_at"]
Name should be self-evident, description clear, and an optional formula may be provided.
### Supported NIPs
As the Nostr protocol evolves, some functionality may only be available by relays that implement a specific `NIP`. This field is an array of the integer identifiers of `NIP`s that are implemented in the relay. Examples would include `1`, for `"NIP-01"` and `9`, for `"NIP-09"`. Client-side `NIPs` SHOULD NOT be advertised, and can be ignored by clients.

25
41.md Normal file
View File

@ -0,0 +1,25 @@
NIP-41
======
Algorithm Filter
------------------
`draft` `mendatory` `author:securitybrahh`
This NIP introduces a way for relays to be honest about how they are filtering the events when a client asks for them
`Relays` MUST advertize thier supported algo's name, name MUST be self-evident (and not a branding), description clear, and a `optional` formula is given if possible
## Querying
For each algorithm, the `relay` MUST allow `clients` to specify the algo as an `algo` query param on the connection URL string
`/r1`, `/r2` etc will be there in a type 2 i.e. aggregator relay
In other words, a `relay` whose regular URL is `wss://relay.url/r1` MUST also respond at `wss://relay.url/r1/algo`
Upon replying to such requests, the supporting `relay` MUST sort the events according to their algo, `limit` accordimng to [NIP-01](01.md) shall be applied.
## Choice of Algorithm
The relay is at the libity to set any criteria for each of their algo GIVEN Name should be self-evident, description clear, and a `optional` formula is given if possible (note even closed source algos can be communicated `honestly` by relays