Subnostr

I agree with 1 because there is no workaround to finding them other than fetching every kind 30001 and filtering and disagree with 2

I disagree with 2 because the list might claim it has kinds X, but it might not, so the client should not depend on what the list claim it has

But wrt #1; it’s essentially the same thing I proposed for the c tag for categories and there wasn’t a lot of buyin so 🤷‍♂️

JeffG 2y ago

I was thinking along the lines of a kind on each tag. Not at the top level of the list. Was that what you were imagining too?

Agree that you couldn’t really trust a list to always give you an accurate list of contained kinds.

Reply to this note

Please Login to reply.

Discussion

PABLOF7z 2y ago

a kind on each tag?? why?

no, I was just thinking literally a `k` tag so that I can do

`{"kinds": [30001], "#k": ["9802"]}`

to get a lists that claim to have 9802 kinds tagged

but now that I type it I don't like it and now I think I should just use a specific kind number for 9802 events (39802? 🤷‍♂️)

Glenn 2y ago

So each new kind would have an associated list kind?

PABLOF7z 2y ago

only the ones that need to be found in such a way

JeffG 2y ago

That emoji list NIP has completely stalled – any thoughts on that approach of having dedicated list kinds? We should probably either close or push it forward.