Update NIP-51 to add shopping cart/wishlist kinds for NIP-15 and NIP-99 marketplace clients

[calvadev]

• Add shopping cart/wishlist kinds for NIP-15 and NIP-99 marketplace clients

[gzuuus]

So, the idea is to create a standard list to represent a cart or wish list using 'listing' tags, correct? If I'm not mistaken, I see a few potential issues with this approach. Firstly, standard lists are meant to be unique per user, which would require overwriting the cart or wish list every time the user interacts with a client and edit that event, user may want to have a wish list and also the possibility to store carts independently. Additionally, NIP99 products are addressable events (30000 <= n < 40000) that can be referenced/indexed using a simple 'a' tag. Therefore, I would propose improving this PR by using a set instead of a standard list. Instead of creating a new tag 'listing', we could use 'a' tags with the event coordinates of the product. This approach would also make it automatically compatible with NIP15 products, as they are also addressable events.

[calvadev]

So, the idea is to create a standard list to represent a cart or wish list using 'listing' tags, correct? If I'm not mistaken, I see a few potential issues with this approach. Firstly, standard lists are meant to be unique per user, which would require overwriting the cart or wish list every time the user interacts with a client and edit that event, user may want to have a wish list and also the possibility to store carts independently.

I initially had the cart and wishlist down as 2 separate lists, but thought keeping one as private (cart) and public (wishlist) could replace that. The user might want to also make their cart and wishlist private and public respectively, though, so two separate lists for that would probably be best.

Additionally, NIP99 products are addressable events (30000 <= n < 40000) that can be referenced/indexed using a simple 'a' tag. Therefore, I would propose improving this PR by using a set instead of a standard list. Instead of creating a new tag 'listing', we could use 'a' tags with the event coordinates of the product. This approach would also make it automatically compatible with NIP15 products, as they are also addressable events.

Just to make sure I understand, the 'a' tag would then contain <NIP-15 or NIP-99 product listing kind>:<product listing pubkey>:<d-tag>, correct?

[gzuuus]

Yes, makes sense, public list (not encrypted) wishlist and encrypted ones private carts.

Just to make sure I understand, the 'a' tag would then contain <NIP-15 or NIP-99 product listing kind>:<product listing pubkey>:<d-tag>, correct?

Yes

[pablof7z]

wouldn't it make more sense to use 3xxxx for the wish lists, so I could have a "wedding wishlist" and "sports wishlist"?

[calvadev]

wouldn't it make more sense to use 3xxxx for the wish lists, so I could have a "wedding wishlist" and "sports wishlist"?

Ahh, yes, that would be best. Was thinking of a way to split out the lists more categorically on the client side, but that solves it.

[gzuuus]

That was what I was mentioning here xD

Therefore, I would propose improving this PR by using a set instead of a standard list.
Definitely makes more sense. Also, will be nice to have an example event using this new list. For the cart, you plan to add some qty value for products?

[calvadev]

That was what I was mentioning here xD

I just realized 😅 I saw set listed as a descriptor for a couple expected tags and assumed you meant that, didn't think to scroll down. For the carts, what benefit would having the unique identifier have, do you think? I can see a potential use case to separate product purchases from service purchases, but generally if listings are consistent across clients, that might not be needed.

For the cart, you plan to add some qty value for products?

The simple solution is to have elements repeated and handle the tally client side; any other thoughts?