NIP-97 Event Recommendations

[vitorpamplona]

This NIP defines a simple protocol for NOSTR-native feed recommendation services as ephemeral requests between two Nostr pub keys: the user and a recommendation provider.

Client applications allow users to subscribe to such services, request recommendations at will and display them on the screen in any way they see fit.

Let me know your thoughts.

[dyng]

Must the Recommendation Response be a response to a previous Recommendation Request? I think it's useful that when users have subscribed to a recommendation provider successfully, the provider could push recommendation event to users continuously (a push-style recommendation).

If the push-style is not always the case, we can have a configuration field in subscription event that allows users to explicitly specify what they need.

[vitorpamplona]

If we turn the request into a registration event, then I think it's better if these events become simple replaceable events (non-ephemeral). In that way, a client can register it's touch points and just download the recommendations using regular filters (as opposed to a request/reponse protocol)

The issue is that these registrations are client dependent. The request's filters is defined by the app (by the UI), not by the client. Apps can have n registrations for different parts of the app.

[s3x-jay]

Just trying to get my head around this NIP. I don't have an opinion yet. Some basic questions…

I don't understand the utility of requesting recommendations for a group of people. Shouldn't recommendations be for an individual? Having the recommendation filter based on the most strict user seems like it's suppressing content. Why not just share recommendations and subscribe to other people's recommendations? (And don't share / subscribe if the recommendation parameters aren't appropriate.)

If you're talking about a curated list of posts… Why not just spin up an account and have a feed of reposts and reposts with comments? What does doing it the way you propose give you that that solution doesn't give you?

If this is about content discovery - then why not beef up Nostr's search capabilities and have a mechanism for user's to save their favorite queries - even grouping them so clients could create a feed of the combination of a set of queries?

Again - I have no opinion. Rather, I'm just trying to understand why this particular way of doing things…

[vitorpamplona]

Thanks for the questions!

I don't understand the utility of requesting recommendations for a group of people. Shouldn't recommendations be for an individual?

Imagine a Nostr video feed playing on a TV. You can get recommendations for everyone watching it AT THE SAME TIME.

If you're talking about a curated list of posts… Why not just spin up an account and have a feed of reposts and reposts with comments? What does doing it the way you propose give you that that solution doesn't give you?

Because it's individualized to the requesting viewer instead of a one-size-fits-all feed.

If this is about content discovery

Search is good. But most content discoveries work via recommendations. It's hard to search for things user don't know exist yet.

[arthurfranca]

Providers are not required to be time-consistent. Every Recommendation Response can be a new list.

I think the filters from recommendation request event should use a page (default "0") attribute along with optional page_limit meaning number of recommendation tags (the recommended data) per page. Like this:

{
  // ..., 
  "content": "{ \"page\": 3, \"page_limit\": 200, \"filters\": [<FILTER1>, <FILTER2>, ...]}"
}

The recommendation response should have the following:

{
  // ..., 
  "tags": [
    // ..., 
    ["page_limit", "10"], // the actually used limit by the provider (maybe I requested 200 but the provider max page limit is 10)
    ["has_next_page", "false"] // (optional) true if has more pages
  ]
}

Considering Providers are not required to be time-consistent and that the sort order isn't chronological, since and until aren't useful for next page requests. With this in place, one would be really able to use this NIP as algorithmic choice for kind 1 feed, for instance. Instead of selecting which relay to read global feed from, the user selects from which provider pubkey.

[vitorpamplona]

Nice idea @arthurfranca, what do you think @brugeman, does pagination make sense in recommendation systems?

To be clear, this would require consistency between pages which creates a stateful session in the provider.

[brugeman]

Nice idea @arthurfranca, what do you think @brugeman, does pagination make sense in recommendation systems?

To be clear, this would require consistency between pages which creates a stateful session in the provider.

I think this NIP is already an algo feed.

Implementing a stateful personalized algo feed is very non-trivial. Provider would have to maintain each user's feed potentially indefinitely, to allow for consistent experience btw sessions, btw different clients. It's like we're trying to reimplement what's really only possible with a centralized network. We can only scroll your algo-feed down until the end of time on Twitter bcs we have an account there, and each acc has a table with all new events written to it by the algo.

Provider returns event ids, not full events. Providers could return say 500 ids (~50Kb), and then client does it's own pagination - downloads the events if user scrolls down. 500 entries is a huge number for a user to consume, they won't really want more 99.9% of the time. Google only returns a couple hundred results (try to paginate behind that), bcs it's too expensive and useless to do more than that.

If some client has a database it can build the longer feed itself, by appending new stuff to the existing log.

I suggest we try to implement it as is and see if the experience is somehow lacking. I think the main issue will be latency, not lack of pagination.

[arthurfranca]

Providers could return say 500 ids (~50Kb), and then client does it's own pagination - downloads the events if user scrolls down.

You are right. This will work if it is highlighted in the NIP like "Due to lack of pagination, it is advisable to return around 500 items at once."

When I first read the NIP, I imagined the provider would return around 10 items without any pagination mechanism so that it would be enough to fill just a small recommendation panel, not a feed.