From 96c40e177fc8a97eee5b3b0f958c7b50411b65ff Mon Sep 17 00:00:00 2001 From: Sovereign Shadow <153613961+securitybrahh@users.noreply.github.com> Date: Wed, 5 Mar 2025 02:11:13 +0530 Subject: [PATCH 1/7] algo filter --- 41.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 41.md diff --git a/41.md b/41.md new file mode 100644 index 00000000..36d88ba5 --- /dev/null +++ b/41.md @@ -0,0 +1,23 @@ +NIP-34 +====== + +Algorithm +------------------ + +`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, its decription in plain english, name MUST be self-evident and not a branding + +## Querying + +For each algorithm, the `relay` MUST allow `clients` to specify the algo as an `algo` query param on the connection URL string. + +In other words, a `relay` whose regular URL is `wss://relay.url/r1` MUST also respond at `wss://relay.url/r1/asc` and `wss://relay.url/r1/seen_at`. + +Upon replying to such requests, the supporting `relay` MUST sort the events according to their algo, and if some events have equil weight in the order, they will be returned in **descending** order According to [NIP-01](01.md), filters with `limit` attribute are replied with events + +## Algorithms + +The relay is at the libity to set any criteria for each of their algo GIVEN the name is self-description, description is in clear language, and a `optional` formula is given if possible. From 4589b7dfb9bb0ebdbb84b08637c3c7994660f298 Mon Sep 17 00:00:00 2001 From: Sovereign Shadow <153613961+securitybrahh@users.noreply.github.com> Date: Wed, 5 Mar 2025 02:36:29 +0530 Subject: [PATCH 2/7] algos & type --- 11.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/11.md b/11.md index 8af4f313..88a05570 100644 --- a/11.md +++ b/11.md @@ -4,7 +4,7 @@ NIP-11 Relay Information Document -------------------------- -`draft` `optional` +`draft` `optional' `author:fiatjaf` `author:scsibug` `author:doc-hex` `author:cameri` `author:victorvsk` `author:snazzybytes` `author:suhailsaqan` `author:unclebob` `author:alltheseas` `author:securitybrahh` Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay's websocket. @@ -12,12 +12,14 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application ```json { + "type": "name": , "description": , "banner": , "icon": , "pubkey": , "contact": , + "algos": , "software": , "version": @@ -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. From 78b70ab6a4a0b4722c47d79c185ce898b879b3ce Mon Sep 17 00:00:00 2001 From: Sovereign Shadow <153613961+securitybrahh@users.noreply.github.com> Date: Wed, 5 Mar 2025 02:39:06 +0530 Subject: [PATCH 3/7] nip typo & type of relay --- 41.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/41.md b/41.md index 36d88ba5..9c9b3c4f 100644 --- a/41.md +++ b/41.md @@ -1,4 +1,4 @@ -NIP-34 +NIP-41 ====== Algorithm @@ -14,6 +14,8 @@ This NIP introduces a way for relays to be honest about how they are filtering t 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/asc` and `wss://relay.url/r1/seen_at`. Upon replying to such requests, the supporting `relay` MUST sort the events according to their algo, and if some events have equil weight in the order, they will be returned in **descending** order According to [NIP-01](01.md), filters with `limit` attribute are replied with events From c5a599525c18fc14cfa6a0f479816ec1b3c43857 Mon Sep 17 00:00:00 2001 From: Sovereign Shadow <153613961+securitybrahh@users.noreply.github.com> Date: Wed, 5 Mar 2025 01:44:29 -0600 Subject: [PATCH 4/7] edit in niop-01 to account for provided algo --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index e2b4ad44..779740ab 100644 --- a/01.md +++ b/01.md @@ -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 From 495709d05603f3aecff7f500dc85e0c7e004e295 Mon Sep 17 00:00:00 2001 From: Sovereign Shadow <153613961+securitybrahh@users.noreply.github.com> Date: Wed, 5 Mar 2025 01:47:48 -0600 Subject: [PATCH 5/7] nip-41 language --- 41.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/41.md b/41.md index 9c9b3c4f..013ad8b3 100644 --- a/41.md +++ b/41.md @@ -8,18 +8,18 @@ Algorithm 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, its decription in plain english, name MUST be self-evident and not a branding +`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. +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. +`/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/asc` and `wss://relay.url/r1/seen_at`. -Upon replying to such requests, the supporting `relay` MUST sort the events according to their algo, and if some events have equil weight in the order, they will be returned in **descending** order According to [NIP-01](01.md), filters with `limit` attribute are replied with events +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. -## Algorithms +## Algorithm -The relay is at the libity to set any criteria for each of their algo GIVEN the name is self-description, description is in clear language, and a `optional` formula is given if possible. +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 From d06bef742a17c91950824124a5a2f27eac1b229c Mon Sep 17 00:00:00 2001 From: Sovereign Shadow <153613961+securitybrahh@users.noreply.github.com> Date: Wed, 5 Mar 2025 01:49:15 -0600 Subject: [PATCH 6/7] 11.md language --- 11.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/11.md b/11.md index 88a05570..43c2f1cd 100644 --- a/11.md +++ b/11.md @@ -4,7 +4,7 @@ NIP-11 Relay Information Document -------------------------- -`draft` `optional' `author:fiatjaf` `author:scsibug` `author:doc-hex` `author:cameri` `author:victorvsk` `author:snazzybytes` `author:suhailsaqan` `author:unclebob` `author:alltheseas` `author:securitybrahh` +`draft` `optional` Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay's websocket. @@ -12,7 +12,7 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application ```json { - "type": + "type": "name": , "description": , "banner": , From f86ac200fe0ff41394f1902cdbbcc5eca8b2bdb3 Mon Sep 17 00:00:00 2001 From: Sovereign Shadow <153613961+securitybrahh@users.noreply.github.com> Date: Wed, 5 Mar 2025 16:07:07 +0530 Subject: [PATCH 7/7] NIP-41 draft --- 41.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/41.md b/41.md index 013ad8b3..203ab399 100644 --- a/41.md +++ b/41.md @@ -1,7 +1,7 @@ NIP-41 ====== -Algorithm +Algorithm Filter ------------------ `draft` `mendatory` `author:securitybrahh` @@ -16,10 +16,10 @@ For each algorithm, the `relay` MUST allow `clients` to specify the algo as an ` `/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/asc` and `wss://relay.url/r1/seen_at`. +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. -## Algorithm +## 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 +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