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.
I think that is the correct flow, yes. Let's summon @hodlbod 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.
also i hate the whole concept and terminology of DVMs there is no insert coin, it's not a vending machine i've seen several things in my time working as a nostr dev that tell me that relay data stores have almost infinite potential and flexibility if you have the imagination