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.

Reply to this note

Please Login to reply.

Discussion

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).