Hmmm, I see. I will say this is adding a few more steps and round trips for centralized classification.
Instead of just adding a few labels in my database and filtering on them I now need to create and store a new event per classification. Effectively doubling my storage requirements on kind 1 notes (that’s all we are classifying for now).
Then clients would query first for 1985s with a certain tag (like topic) and then for the e tagged events in each 1985? Is that the correct flow?
I actually think a DVM might make more sense than that for us with strictly the goal being interoperability with clients.
But, DVMs are just REQs with extra steps for this particular use case. It’s still a centralized classification no matter how many intermediaries I add.
Not if you use a well defined interface or open source the implementation. It also doesn't require a single comprehensive index if we do it right.
My use case is to offer our proprietary classifications to subscribers of filter.nostr.wine. It’s expensive to run our classifier. What’s do we accomplish by adding DVMs or other middle men?
I asked previously if anyone would be interested in funding an open classification action initiative but there didn’t seem to be much interest. For now I’m moving forward with the self funded proprietary version so I can start improving the data.
I think DVMs are generally only useful if they aren’t run by relay operators and either aggregate results from multiple relays or fulfill a job outside of a web socket.
Nostr.wine running a search DVMs, for example, instead of using NIP-50 when search is inherently centralized anyway is just adding extra steps without obvious gain. This feels similar to that but I could be way off?
I think the best way to decentralize this would be NIP-32 labels by several classification providers across several relays. Perhaps a DVM could help aggregate these for quicker responses.
I am not sure, however, how we find people to run classification models and provide those labels publicly for free.
Ok last post I’ll bring it full circle, sorry for all the spam. I’d consider this separate to the current implementation but..
I could make a DVM that accepts event(s) as input and charges for their classification. The paid classification could get published widely via a NIP-32 event. Then we slowly build an open classification database paid for by users? Does that make any sense?
Yeah, I think everything you said makes sense. The benefit of adding DVMs into the mix would be to foster interoperability through a standard interface that works for free/open providers, or for multiple paid providers to compete on quality of service rather than quality of interface. So building for DVMs run separate from relays. Maybe that's not optimal for you, but it's healthier for nostr as a whole (and easier for clients to integrate).
I think that is the correct flow, yes. Let's summon nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn
But you don't have to store anything, you can generate these events on the fly upon seeing a REQ.
I am now thinking that another option we have is to specify these extra meta things on NIP-50. Like the search string could have a "category:nsfw" segment and then the relay interprets that in any way it wants.
Yes, I could generate them on the fly but for large limits that could be pretty slow at scale without some caching.
I think extending NIP-50 for this would make sense. I know there are a lot of strong feelings about that NIP already so perhaps a refining of it could expand the flexibility and options.
WHO DARE SUMMON THE GREAT AND MIGHTY HODLBOD
yeah, that sounds reasonable. I also like DVMs for this kind of thing, since they can be dynamically applied to any dataset in theory, and multiple instances of the same dvm can exist. This doesn't seem centralized to me. Nip 50 in contrast does centralize, because it couples the relay's dataset with the relay's functionality. See my blog post for more details:
naddr1qqxnzdesxqcn2df5xymnzdp4qgsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgsrqsqqqa28q3wd45
