From af4f963e0c388efc7d4bb6566b88bb6be5ddd54e Mon Sep 17 00:00:00 2001 From: arthurfranca Date: Wed, 28 Jun 2023 11:06:54 -0300 Subject: [PATCH] Require extra endpoint --- 34.md | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/34.md b/34.md index 73ffbd44..5b2ef227 100644 --- a/34.md +++ b/34.md @@ -12,12 +12,12 @@ sorted in **descending** order by the `created_at` event field (newest events fi For filters containing `limit` attribute, this NIP-34 adds `nip34` as a new filter attribute whose value indicates the algorithm the `client` wishes to use for sorting events. -For instance, if a `client` sends the message `["REQ", , { kinds: [1], ..., limit: 5, nip34: 'a' }]`, +For instance, if a `client` sends the message `["REQ", , { kinds: [1], ..., limit: 5, nip34: "a" }]`, it is asking the `relay` to sort five kind 1 events in **descending** order by the `nip34a` event field instead of by `created_at`. In the above example, `relays` that want to support the NIP-34a algorithm must add the `nip34a` event field to each event saved to their internal databases. The new field is populated following rules described at the NIP-34a NIP extension. -Besides that, upon replying to such requests, the supporting `relay` MUST add `nip34: { score: '' }` field to each returned event JSON. +Besides that, upon replying to such requests, the supporting `relay` MUST add `nip34: { score: "" }` field to each returned event JSON. It is a backward-compatible proposal because non-supporting `relays` ignore the `nip34` filter attribute and sort by `created_at`, as usual. @@ -44,13 +44,24 @@ Into this: `SELECT * FROM events WHERE kind in (1) ORDER BY nip34a DESC LIMIT 5` +## Relay Extra Endpoints + +`Relays` MUST make available an extra URL `clients` can connect to for each supported NIP-34 algorithm. + +For example, if supporting the NIP-34a algo, a `relay` whose regular URL is `wss://relay.url/r1` must +also respond at `wss://relay.url/r1/nip34a`, i.e. the additional URL has the algo field name appended to the path. + +Then when `clients` connect to `wss://relay.url/r1/nip34a` and request events using `limit` +filter attribute, the relay will automatically sort events in **descending** order by the `nip34a` event field instead of by `created_at` when replying. Clients can still override the chosen algorithm if using the +`nip34` filter attribute. + ## How Clients Make Custom Requests for a Specific User The algorithms are generic, meaning the "score" represented by the new event field does not differ for different users. However, smart `clients` may keep track of pubkeys from whom the user is consuming content, also hashtags, for instance, and use such pubkeys/hashtags as a way to tailor the query to that specific user. For example: -`["REQ", , { kinds: [1], limit: 5, nip34: 'b', authors: ["pubkey1 user follows", "pubkey2 user has read content from recently", "pubkey3 that user has liked content recently"] }, { kinds: [1], limit: 5, nip34: 'b', '#t': ['cat', 'bitcoin'] }]` +`["REQ", , { kinds: [1], limit: 5, nip34: "b", authors: ["pubkey1 user follows", "pubkey2 user has read content from recently", "pubkey3 that user has liked content recently"] }, { kinds: [1], limit: 5, nip34: "b", "#t": ["cat", "bitcoin"] }]` ## Rules for Submitting a NIP-34 Algorithm