Nostr Web Client

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?

fiatjaf 1y ago

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.

Reply to this note

Please Login to reply.

Discussion

Mazin 1y ago

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.

hodlbod 1y ago

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