I think there are two benefits of having the kind of each list item upfront

1. it would make searches a lot more efficient for relays.

2. it would make it easier to decide how to render content for clients like Listr

Reply to this note

Please Login to reply.

Discussion

You guys are the experts, but I agree. It seems like there is something to be done here. Just my 2 sats.

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 🤷‍♂️

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.

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? 🤷‍♂️)

So each new kind would have an associated list kind?

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

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.