nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc I'm enjoying using #NDK, thanks!

Reply to this note

Please Login to reply.

Discussion

Most thanks should go to nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft but thank you all the same.

thanks to both of you!

I'm trying to make a list of NIP-94 events on listr.lol, a 30001 type list, but I keep seeing "loading event..." where I'd expect it to resolve on the list. I'm specifically trying to add note1ah59ltfxjyftmj8s93kyzsuzvap8cq9r609ejrfaug7ex92q653sqfl9ct. are kind 1063 allowed in bookmark lists?

Anything is allowed in a NIP-51 list

Yeah that’s right. What’s happening is that listr doesn’t know about many kinds so it’s never going to figure out how to load that item. I’ll have a look tomorrow and see what I can do there.

Would love to know what data from those events you’d want to see the list as well!

I'm working on creating lists of RSS feeds. on those kind 1063's I care about the `url` and `m` tags.

This is unfortunately more complicated than I thought. For your list, I actually can't find any of those events when I query by ID. Do you know what relay that might be coming from?

I have to apologize. I went back and checked, and my publisher code is apparently not working, so those events are not published. just prior to that I did manage to publish some to nostr.wine at least, but I believe also to relay.damus.io. sorry, I'll sort this out and let you know how it goes. I'm using ndk to publish these 1063 events.

No worries. Let me know when you have a list that’s ready and I’ll pick it up again.

I did finally get the kind 1063 events published and listr displays them as I'd expect.

I do have a remaining question, which is how to add replacable events to a list? e tags imply a hex event id. would "naddr" as a tag work? the nip-51 writeup doesn't mention it, nor does nip-33 or even nip-19.

oh snap, that's it, thanks!

Ndk svelte’s component event content man, I’m telling you

That’s exactly what I was thinking of 🤙

Would it be useful to add a description tag to list items to be used as a fallback for rendering?

I think a k tag for kind 30001 lists would be helpful.

Since list items are just Tags (just an array of two strings) there isn't a way to add a description to them.

And adding a k tag would work I guess, but only for lists where the items weren't mixed. Just a bit off spec I guess.

Makes sense. Would it work to have an optional marker on the items, like an alt tag for an image in html?

[‘a’, ‘, , ‘marker’]

Markers might be good but not as alt tags.

What’s your take on the use of markers?

I like them when they make sense which might not be very often; it seems like if you’re relying on markers for something too complex you’re probably masquerading upstream complexity which should be solved differently

So I guess I don’t like markers for this case? I dunno, sounds like I talked myself out of it

Maybe show an example of where you want them?

I think, generally speaking, it would be useful to be able to fetch a list based on its contents.

And have some rudimentary information about each list item without having to fetch each item.

My rudimentary solution is to use a k tag on the list which can be a string of kinds of the items in the list. As you said, this could be a lie. (womp womp)

And then to use markers as a rough way to determine what the item is without fetching it.

But, I’m sure there are more-better solutions and I appreciate the discussion.

Ultimately, I will follow the conventions you and nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc are using because you are blazing the trail with lists. Also, once there is consensus, I’m sure it will make it into #NDK.

if you're adding NIP-33 events to your list at least you know the event kind without fetching it, to me the `k` tag is useful to find those lists.

I'm still curious about the markets, do you have a real world example of what you're using them/want to use them for?

DM’d you my outline. Watch out for noob stupidity. 😂

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

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.