I would say what I was going to say but you already know what I would have said.
But they allow for long-tail algorithms that could be interesting for a particular set of users:
“Give me trending notes for my npub”
I think this model wins because it allows a developer to write 5 different and weird algorithms in one day, even if those algorithms only have 10 or 20 devoted fans
Yep, DVMs the user can subscribe to are way better. But we need to figure out how to log down which DVMs the use wants to use for each task.
NIP-89?
“I use DVM npub1XX for kind:job-req-feed-generation”
Or even
“I use DVM npub1XX for kind:job-req-feed-generation, t: ‘bitcoin’”
As long as there is a way to break further down from event kind, it should work.
What do you mean “break further down from event kind”?
You mean the kinds the DVM will take into account? That’s a param for the DVM:
[ “param”, “kinds”, … ]
No, the kinds to classify nip89s apps by. Right now it's only by event kind. We need to do “I use DVM npub1XX for kind:68001:job-req-feed-generation"
So, you can filter nip89 apps not only by kind, but by each individual type job being offered.
Each job type will be it’s own kind by suggestion from nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
I initially left just one and then a j tag but a kind per job type makes much more sense.
(I haven’t published the revised NIP yet; I’ll try to push it today)
Yep, that makes a lot more sense :)
And then you can see people you care about’s algorithms and even the results of the feed at a particular point in time
