So here is the first implementation of this to play with:
nostr:npub1jhcdz68ms88ecqwz4kzyv7ey30e335744fjtwp204h5u3q4l4v4qqxwjqd - returns trending posts
nostr:npub1z23sfvrlvfrvtvv00avvxldcy909a6y33jfmsj3595q52p6lfd2q7hu2y3 - returns trending profiles
These pubkeys are listening to relays listed in their contact list, and writes results back to relays in the request tags. It ignores the filters for now.
Here's a question for you. I was considering a replaceable event that is updated by the provider all the time as opposed to a request/response procedure protocol.
A replaceable event will be easier to code by clients (just subscribe to event x) but I didn't know if it made sense for providers to keep updating a list of recommendations every time a new post comes into the list.
Now that you have coded it, do you think the request/response procedure was a good choice?
I think it's kind of annoying to code this RPC, I have to juggle with relays like all clients do, and it adds a lot to latency. I could just publish NIP-51 list w/ trending stuff periodically on some number of relays and achieve the same goal. But that's only for global trending stuff which is not updated too often and is same for everyone.
But when it comes to personalized recommendations - RPC allows you to pass parameters. I tried doing a specialized relay like data.nostr.band, but that has lots of other problems, I don't like that route.
So I think this RPC style is superior and is a great idea, we just need to build good tools to manage relays and keep persistent connections to reduce latency.
One huge downside here is privacy - everyone can see what requests I am making. We could encrypt the content and filters, but that's still annoying
There is a common pattern that’s not well defined yet in Nostr that is effectively a cached result. It’s stateful and typically either expires by time, or expires when replaced.
An example could be how much credit you have used for a paid service. Goes up and down on payment and usage.
Another example is a list of current trending events or similar, updated hourly or daily.
One consideration is how and when to update. Schedule is ok, however a client bump to update their usage to be current is likely a valid case too.
It’s basically a snapshot of data that’s useful as an event and more (likely) accurate the closer to its creation time, however it’s content changes.
