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

Require extra endpoint

Browse Source
This commit is contained in:
arthurfranca 2023-06-28 11:06:54 -03:00
parent 31f73278e3
commit af4f963e0c
1 changed files with 14 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
34.md
View File

@ -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", <sub_id>, { kinds: [1], ..., limit: 5, nip34: 'a' }]`,
For instance, if a `client` sends the message `["REQ", <sub_id>, { 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: '<nip34a value>' }` field to each returned event JSON.
Besides that, upon replying to such requests, the supporting `relay` MUST add `nip34: { score: "<nip34a value>" }` 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", <sub_id>, { 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", <sub_id>, { 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