Oh, that's why NIP-32 exists: "labels" are just tags assigned by other people.
Discussion
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
this is for the case of propagating that "opinion"
nostr:nprofile1qyf8wumn8ghj7u3wd4kx26m49ejx2a30qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qpq8kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sksrfanak is talking about a proprietary, internal thing that he is charging access to
just pointing this out, the tags i mentioned were FILTER tag fields, both filters and events have them, remember?
Yeah this conversation has gotten to be way too complicated. We are all talking about different things.
I fixed the nostr.wine issue try now. Apparently I broke one mirror during a restart earlier today :(
i was never unclear that i meant FILTER tags, you just didn't catch it
that's something you can easily add to a random new NIP that augments NIP-1
the internal tagging system is internal, it's irrelevant, except that it relates to the clients requesting it, so it's FILTER tags not EVENT tags
My understanding of NIP-01 is that filter tags are meant to relate directly to event tags - that’s why there is confusion.
ok, that makes sense but ultimately filters are just a query API and nothing says they cannot extend beyond simple matching if the database can do that
this will simplify your code a lot if it's just a small extension of tags instead of the whole REQ, simpler to adopt or reject, or ignore... it won't match, obviously, for relays that don't understand it, i'm not sure what that behaviour is though
that is an issue that needs to be figured out then i guess
the naive, intuitive sense of it is that filters are queries and thus they need to be more flexible than the data they relate to