NIP-34 - Algorithmic Filter #579
Conversation
|
Should each algorithm be a new nip like NIP-3401 (instead of just I see there's also a |
|
I like this. |
|
Joy! Would it be extra to make nip34 take an array? Some algorithms might take arguments that clients might want to expose. It could be best to keep it simple though and add some other |
|
@huumn What kind of args you anticipate? This NIP seems incompatible with args cause the score field isn't calculated on each client query but previously However, the good thing of being a REQ extension is that the client can be smart by keeping track of pubkeys from whom the user is consuming content, also hashtags, and use such pubkeys/hashtags as a way to tailor the query to that specific user like this:
|
Sorry I missed that. Should we be telling relays how they should be
In the case of ranking by likes I guess this would mean my feed could be influenced by anyone, so long as other filter conditions are met, ie there's no way for me to filter out the influence of likes by people I've muted for instance. I do really enjoy how simple this is. Nice work.
One example is whose likes we want to take into account. The simplest version is just a boolean flag, e.g. true if I only want my follows considered, false for global. |
|
Each algo section on the NIP describes how relays should compute the score. It's a global score so can't avoid muted ppl weight. Relays should atleast rate limit likes and such by ip to avoid gaming the score. |
|
This seems really similar to the atproto solution. That's one of the few areas where they're farther along than nostr. |
arthurfranca
force-pushed
the
nip-34
branch
2 times, most recently
from
eb49042
to
3430c36
Compare
|
Took the route of adding NIP extensions for each algo to use "supported_nip_extensions": ["34a", "34b", ...] etc from NIP-11. |
|
I have added a new simple algo to address issue #78 |
|
This sounds like a good solution, but before this is tried I think we need a more developed client ecosystem first, in which clients are more prepared to differentiate between relays. |
|
On the other hand, if clients get to that point, it would be easier for a relay to just offer different endpoints which users can specify manually by using URL paths. This would ensure maximum compatibility with clients that do not explicitly support algorithms. |
The client? Or you meant a relay besides supporting { "nip34": "algox" } filter field could make available wss://relay.url/nip34algox in addition to regular wss://relay.url for users to add to relay list on unsupporting clients? |
|
Yes, that's what I mean. I fixed my comment to say "relay" instead. |
|
@fiatjaf I've added it as a requirement. |
|
It ocurred to me that the algos don't need to return a string because DBs that can only index strings already have to deal with integer for the created_at field. |
|
Now Ascending and Seen At fields are integers. |
|
Wherever we're heading with this, I think the entire thing should be in a single file. |
|
Ive put everything in one file and simplified text a lot |
|
related: #78 |
|
I'm biased but if this gets merged and relays start supporting this, the protocol gets both a simple way to do client-relay event sync (seen_at) and to reverse sort events (asc). Huge win for clients that keep a local DB so would appreciate sync or to those that don't have a local DB and would like to reverse sort events relay-side. More involved algorithms can be added in the future as an extension. Like NIP-11 |
|
Why do this with an extra parameter in the filter instead of a subdomain or a path in the relay URL? I think the later is better, more flexible, more transparent and easier to grasp. i.e. instead of sending |
Not to be annoying, but the order is: relays start supporting it and then it gets merged. :) |
|
@fiatjaf because the same connection can be kept open and reused for subscriptions that use or don't use NIP-34 (side note: the field name is now "algo" instead of "nip34" cause don't know if gonna have to change nip number). I already added the Relay Connection URL Query Parameter section with what you said, to be able to manually add relay urls on clients that don't support this nip. @vitorpamplona fair T_T I haven't seem many relay implementers on NIP discussions lately |
Before going on with NIP text, I would like feedback on the concept below. It is simple but hard to explain. It is a way to enable algo decentralization by making algos work in any dumb relay instead of Google algo that works only on Google relays. Please tell me your questions if any.
With the above quote in mind, we could turn this:
["REQ", <sub_id>, { kinds: [1], ..., limit: 5 }]Into this:
["REQ", <sub_id>, { kinds: [1], ..., limit: 5, nip34: 'algorithm_a' }]Then, non-supporting relays will (probably) just ignore the nip34 field and sort by
created_atin descending order, as usual (this detail is important because it is what makes it backward-compatible).While supporting relays (that not only support nip34 but also algorithm_a) will just swap the
created_atfield in their internal query with anip34_algorithm_afield.I want it to be a simple swap of fields. For example, if a relay implementation uses a SQL DB, the above filter would turn this:
SELECT * FROM events WHERE kind in (1) ORDER BY created_at DESC LIMIT 5Into this:
SELECT * FROM events WHERE kind in (1) ORDER BY nip34_algorithm_a DESC LIMIT 5So:
If the concept is acknowledged, I will kick start the NIP with a simple algo that will enable us to sort events in ascending order. Such feature is useful for instance on github-like PR discussions that have older messages at top.
Original discussion