Oddbean

David. I think you’re onto something really big here… but the iceberg goes deep. - The use case for “auto generated lists” (as we are imagining) is novel to Nostr. It’s not exactly “covered” by design in the NIP51 spec nor accounted for by any client developer. - and even as they are, lists are not really used by clients in ways that they could or should be. - these two facts go hand in hand … because lists are assumed to be “made by hand” then clients don’t implement them as data stores for various needs, because that would too much to ask of end users. - so there’s a paradigm shift we’re up against which will be more work to change than just designing a “d tag standard”. But also… that’s a good idea. 👍🏼

This is very insightful. I hadn’t thought of it quite that way. My naive impulse is to store many pieces of info in the d-tag, as dictated by the fact that the d tag is what’s used to update NIP-51 lists, but then to store each or every of those pieces in their own customized tags if we think a client may want to search based on those tags. I have used this technique in my initial nostr implementations of the concept graph. And when that gets too complicated … I have solutions but I don’t want to go there yet. Way too deep for this thread. We won’t solve everything at the stage we’re at right now. What do you think of my naive impulse? Keeping in mind that our immediate path forward must address the paradigm shift you mention.