Feed organization and discovery proposals (social algo servers)

[earonesty]

Nostr nip's currently support:

• requests for "all events except what i consider spam"
• requests for "all events matching keywords except what i consider spam"

Ideally relays and proxies and aggregators should also support

• requests for "my custom algorithm & event weighting/tagging"

(I don't see a specific proposal for how this should be handled)

Obviously it could be handled on the client, organizing events by things like "number of followers in common" and "number of likes" and "number of zaps" and "content that matches stuff i clicked like on in the past"

But since likes, zaps, followers are all transmitted, and since mobile clients are ideally lightweight, it might be useful to have a "content organization server"

Currently users that want this feature must have a single inbound relay that does everything for them (aggregates, filters, organizes, broadcasts to as many relays as they need to cover their followers). This can hinder the growth of censorship resistance.

Idea:

Content organization (also called "social algorithm") servers should receive the pubkey of the user making the request, as well as their current state token (cursor pointer)

They respond with:

• lists of event ids along with proposed label/value pairs
• lists of npub ids along with their proposed label/value pairs
• a new cursor id

label/value is just a string/number or a string/bool value

Value ideas:

• floats between 0 and 1: meaning a likelihood
• integers: meaning a sort order
• boolean: true/false

Examples of labels:

"spam": 0.95
"priority": 9941
"blocked": true

Most clients should only ever have one content organization server at a time - even if they have many inbound relays. Clients should be able to enable/disable content filtering and organization easily.

Something like this could be flexible enough to handle:

• spam filtering
• blacklisting
• top/noteworthy events
• basically anything

[fiatjaf]

Don't you think this is a giant centralization vector that should be avoided?

[staab]

This idea has already been thrown around a fair amount, personally I think the best option is to keep most use cases in-protocol as much as we're able following https://github.com/nostr-protocol/nips/pull/259. In that PR I explain why adding more advanced features to relays using a recommendation extension to the nostr info document can help ameliorate the centralization problem @fiatjaf has mentioned.

[earonesty]

i think it will prevent the centralization that is occurring. i just switched to a single inbound aggregator to deal with this. so now i never find out about notes that they filter, and just trust him to show me stuff. the experience is so much better than before, i'm not going to switch any time soon. NIP11 is exactly what we want to avoid (more centralization)

[fiatjaf]

What are you talking about specifically, @earonesty?

[earonesty]

• i started with a large collection of relays, like 10 of them, to be certain i can get notes from everyone i follow
• however i want to be able to apply a sorting and ranking algorithm to the data, using a naive bayesian filter
• my mobile device can't really do this
• i can subscribe to a proxy that does this for me
• now i have 1 inbound relay instead of 10 (bad)

be cool if there was a way to do "social algos" (ranking, reputation, priorities, etc.) while retaining decentralization (no reduction in relay connections, keep a simple relay protocol), where the client could subscribe to an "algo server" that did these things, but didn't retain notes, and only gave you noteids along with the labels and rankings. then you can "use it or ignore it", have multiple filter providers, compare them, drop them, etc. while retaining the same relay set.

[earonesty]

but maybe doing it "out of band" is too complicated