A fallback is a bad idea imo; if you can’t find the event just skip it
What would be the k tag for? To identify the kind of events in the list? I had a similar idea for highlighter which I’m still contemplating whether to do; what’s your reasoning for it?
In my case, I’m looking at using kind 31974 (or something along these lines) for player characters in a game.
Also looking at 31973 for games/campaigns. Game hosts and players could organize their games into lists.
So I could use a k tag in my app to fetch lists of games or lists of characters by kind.
If there is a better way, I’m totally open to it.
In your own app it's easier than that since you already know what kind you want to get back from relays.
If you're going to be loading kind 3000x lists then the kind would be helpful because you'd want to have a way to go through the user's lists and only show the ones that are related to the game rather than mute lists for instance.
This came up in a NIP PR a month or so ago about emoji lists. There was some discussion about whether it's better to create new list kinds for specific types of items. Right now we have 30000 and 30001 which are supposed to be for people and "bookmarks" respectively but, in reality, people often mix kinds of things that they put into lists.
Yeah. My thinking was, game hosts will want to make lists of their games like “DnD Campigns” or “Shadowrun One Shots”, “Monopoly”, “Risk”.
Every “game” would be a kind 31973.
Players may want to organize their characters (kind 31972) in lists too.
I’m aiming to make an app where game hosts can bring the game system they want to the app and invite players to the games.
Honestly, I wanted to point them to Listr to make their lists. 😂
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
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? 🤷♂️)
