Working branch

[gzuuus]

Here we can work and discuss

[gzuuus]

I've just pushed a commit that aims to reduce ambiguity in shipping inference. By treating the product as the top-level element in the marketplace, I've introduced a new way to associate shipping options with products. Specifically, you can now use the product collection coordinate in a shipping tag to indicate that the shipping settings defined in the product collection should be applied to the product. Additionally, I've added the ability to encrypt product drafts.

[sovbiz]

Some of the notes i’ve made during the week from some of our talks:



usage of NIP-89 ( Client Tag for order ) Not mandatory but interesting to see from where the order is created.



The Payment flows we should promote is closer to Nostr Native.



1. E-cash as a means to settle over DM ( Locked to Npub )
   
2) Lightning Bolt 11 & Bolt 12 from the Kind 0 -> Lud16
2. Server ( BTCpay … LNBits )



This week i was also thinking about how to do a fiat gateway:
Using Nip-69 by pushing an order to ( Robosats, … )


 for either the merchant to resolve.

I'll try to document some of this hopefully this week 🫡

[gzuuus]

Yes, all sounds good, payment flows closer to nostr native should be promoted over hosted solutions. The hosted solution can also benefit from a DVM where the user defines how he wants to be paid and the DVM responds with the payment details at checkout... Just an idea, but both ways, pure nostr based on kin0 data and hosted, should be considered.

Wow, genius idea to use nip-69 as a fiat gateway 👀

[gzuuus]

How do you think merchants can specify their preferred payment method? Consider a scenario where a merchant can receive e-cash via npub and also has a Lightning Network (LN) address attached to their profile for receiving zaps on Nostr. Generally, we are assuming merchants want to use these methods to receive payments for their products. I think we should define a simple way for merchants to indicate whether they want to use their native Nostr details for payments or prefer manual (interactive) or server-based methods. For simplicity, this could be a boolean value, e.g., native-payment = false | true. This field could be placed in the kind 0 or, for better control, defined at the product or collection level. It is also possible to use a string instead of a boolean, such as payment-preference = ecash | lud16 | bolt12 | manual, where manual can be used together with a server. What do you think?

I believe merchants should be able to specify their preferred payment method, as receiving payments as a merchant differs from receiving payments for social interactions (e.g., zaps). The latter can compromise the merchant's privacy if their details are public

cc @calvadev @sovbiz

[calvadev]

How do you think merchants can specify their preferred payment method? Consider a scenario where a merchant can receive e-cash via npub and also has a Lightning Network (LN) address attached to their profile for receiving zaps on Nostr. Generally, we are assuming merchants want to use these methods to receive payments for their products. I think we should define a simple way for merchants to indicate whether they want to use their native Nostr details for payments or prefer manual (interactive) or server-based methods. For simplicity, this could be a boolean value, e.g., native-payment = false | true. This field could be placed in the kind 0 or, for better control, defined at the product or collection level. It is also possible to use a string instead of a boolean, such as payment-preference = ecash | lud16 | bolt12 | manual, where manual can be used together with a server. What do you think?

I believe merchants should be able to specify their preferred payment method, as receiving payments as a merchant differs from receiving payments for social interactions (e.g., zaps). The latter can compromise the merchant's privacy if their details are public

cc @calvadev @sovbiz

I think it might be sufficient to just leave it up to the user to decide if they want to use their checkout method, and if not, they use a different site. It adds a bit of a burden on clients to potentially have to implement every type of payment type when they might only want to support certain ones.

[gzuuus]

You're right that it should be up to the marketplace to offer compatibility with different payment methods. However, there's an interoperability issue that needs to be addressed. As a merchant, I prefer to receive payments on-chain, either because my products are expensive or I simply prefer not to use other payment methods.

Consider a scenario where Market A offers checkout options for on-chain and other payment methods, allowing users to specify their preferred payment method within the marketplace. In this case, I publish my products on Market A, indicating that I only accept on-chain payments. However, my products also appear on Market B, which doesn't support on-chain payments or payment method preferences. Despite this, Market B still allows users to purchase my products without considering my preferences as a merchant. This creates a problem, as I may receive undesired payments, and users may send money without any guarantee that I will deliver the products.

To resolve this issue, I propose using NIP-89 (Recommended Application Handlers) to enable merchants to specify a preferred app for users to purchase from them. This approach allows merchants to express their preferences and avoids interoperability issues.

Alternatively, other solutions could be implemented, such as adding a 'payment-preference' property at the product or kind0 level, as I was describing before. This property would be an array listing the desired payment methods (e.g., on-chain, lud16, bolt12, etc.). A more exotic idea would be for marketplaces to use an npub, and then, together with the merchant's npub, use Diffie-Hellman key exchange to create a shared key. This would allow users to define configurations per marketplace, enabling merchants to explicitly define how users should interact with them depending on the marketplace. However, I believe that using NIP-89 is the most straightforward and nostr native approach, as it would enable marketplaces to display merchant preferences and avoid problematic scenarios. WDYT?

[calvadev]

I do quite like the NIP-89 approach, simple but still considers user preference. One could also specify payment preferences for a collection of products, say, for larger purchase only on-chain, very small ones only ecash, etc.

[gzuuus]

I also like this idea.

One could also specify payment preferences for a collection of products, say, for larger purchase only on-chain, very small ones only ecash, etc.

How would you implement this? Would you use a payment-method tag or something similar in the collection event?

I've been exploring another idea, which involves utilizing the payment fields in the kind:0 event. Currently, lud06 and lud16 are commonly used, despite not being documented in any NIP, including NIP24. Typically, these fields are used in the format ["lud16", "<ln-addrs>"]. However, we could consider adding a third item to the list to define the scope of the payment option. I'm still thinking about the best format for this. One option could be using a label, such as ["lud16", "<ln-addrs>", "<zaps | shop | all>"], although I haven't given much thought to the specific labels yet. Another possibility is using a Unix-like octal style, for example, ["lud16", "<ln-addrs>", 777]

[sovbiz]

Sorry folks got pretty sick so still catching up on some things, i'd think the flow as defined where you set the shop default in the kind 0 makes allot of sense, same for shipping to some extend, and than have them like you mentioned on the product itself either making them the exception to the rule. At product creation clients can than set the defaults for each product.

Pushing the checkout flow to the client from where the product was created for some of the more complex payment flows makes the UX probably as smooth as it can in the beginning.

[gzuuus]

Ey, I hope you're doing well! How are you imagining this kind0, how it will look, I'm not seeing the shipping case rn?

I've been thinking about the possibility of adding scopes for payment fields, such as lud06, lud16, bolt12, and cashuPReq, among others. This would allow you to define different public payment methods in your kind0 and specify their scopes for apps that may be interested, like marketplaces. For each payment field, you could define whether the payment method is for general use or specific use cases.

Initially, I considered using labels or Unix-like octals, but upon further reflection, I realize that both approaches have limitations. A potentially better solution would be to use NIP numbers, following the same principle as NIP11 for relays. This would involve defining a list of compatible NIPs, resulting in a format like ["lud16", "my@lnaddress.com", "57, 99"]. In this example, the payment details would be compatible with NIP57 zaps and NIP99 market. If there is no third item in the payment details, we could assume it's for general use. This method would also enable defining multiple payment details of the same type, such as one for zaps and one for market, like ["lud16", "my@lnaddress.com", "57"], ["lud16", "my2@lnaddress.com", "99"], but this is just a silly example since the latter would be just the same as ["lud16", "my@lnaddress.com"] for general use.

What are your thoughts on this approach? I believe it could effectively address the case for public payment details. For private payment details, I'm considering using NIP78 (app-specific data), where the user can create an encrypted event for the market app's public key, allowing the market to decrypt it if needed. To signal this, the user could rely on NIP89 app handlers, as we previously discussed.

[gzuuus]

I've been thinking about another idea to address potential stock mismatch issues. When a merchant's product is listed on multiple marketplaces, customers may successfully complete the purchase process on different platforms, or multiple customers may successfully complete the purchase on the same marketplace. To mitigate this, marketplaces could signal this event and virtually reduce inventory by sending an edit request to the merchant's product event. This approach would be similar to the one used by Amethyst for edits and edit suggestions .
Here's how it could work: when a customer buys a product on marketplace A and the transaction is successful, the marketplace can publish an edit request to the merchant suggesting that the product's inventory be updated with a new value. This would create a virtual inventory reflecting the potential inventory mismatch. This virtual stock could be visible to other customers, potentially saving them from dispute scenarios. Once the merchant gets online, it can accept the orders and reduce the stock of the product.
Another possibility is to set up a federation between marketplaces, such as Market A, B and C. These marketplaces could join together and listen to each other's edit requests to get a more accurate picture of the actual stock of the product. This would allow them to better manage inventory levels and reduce the likelihood of mismatches. Of course, this should be done with trusted parties to reduce the potential for abuse.

[sovbiz]

Hey maybe a suggestion for in the new year is to setup a call to go over the finalizing stuff on this proposition, also another suggestion is to add or maybe have the folks from https://conduitbtc.com/ involved ✌️

[gzuuus]

That sounds great! We can set up a call in early January if that works for you. They recently wrote an article in nostr about conduit and tagged me and plebeian. I replied to the note, pointing out the work we are doing here, but never heard back from them, hopefully we can have them involved.

[sovbiz]

First week of januari is still a bit slammed but just to suggest a date 10 januari 21:00 GMT, I think that still aligns with @calvadev depending on what timezone you are in in the USA, i'm going to ask the conduitbtc folks to join the convo here.

[calvadev]

Yeah I think that works. If I got the time conversion right, that's 4pm my local time where I'll be at (Eastern).

[amunrarara]

Hey rockstars, Acea Spades from Conduit here. Awesome to see this PR thread, and I'll take a deep read as soon as the holidays crank down a bit.

I'll drop a link to the article I wrote recently, addressing some of these issues with an opinionated path forward for some of the NIP-15 issues; we're primarily interested in mitigating the manual checkout resolution and possible Lightning invoice expirations, among some other things.

https://yakihonne.com/article/naddr1qq257drwx94rzs2lwyey7a33v43nqjj4w4j85q3qnkfqwlz7xkhhdaa3ekz88qqqk7a0ks7jpv9zdsv0u206swxjw9rqxpqqqp65wp3t053

My partner @ericfj got a ping from @sync with an invite to the Jan 10th call, it would be awesome to be there. I'll read up on this thread here and come prepared to rock and roll.

[amunrarara]

Also, sidenote, I have two PR's open right now to update the NIP-15 spec, though the improved DM encryption PR needs a solid revision, it contains some nonsensicals and an overlapping Kind (30030). I've been focused on other matters, but I'll prioritize 'em in the upcoming month.

nostr-protocol#1648

nostr-protocol#1420

[amunrarara]

Also starting to ponder Product Variants. T-shirt sizes, for example, each with a different price, with most other details the same.

Could be achievable by a "variants" tag with nested overrides, perhaps? Is nested tags a thing in Nostr? Could be bad form, but a possibility.

["variant", ["price": "123.45", "USD"], ["size": "XL"], ["title": "Super Cool Shirt - XL"]],
["variant", ["price": "125.43", "USD"], ["size": "XXL"], ["title": "Super Cool Shirt - XXL"]]

[calvadev]

Also starting to ponder Product Variants. T-shirt sizes, for example, each with a different price, with most other details the same.

Could be achievable by a "variants" tag with nested overrides, perhaps? Is nested tags a thing in Nostr? Could be bad form, but a possibility.

["variant", ["price": "123.45", "USD"], ["size": "XL"], ["title": "Super Cool Shirt - XL"]], ["variant", ["price": "125.43", "USD"], ["size": "XXL"], ["title": "Super Cool Shirt - XXL"]]

Specifically for sizes, at the moment I add a "size" tag to the NIP-99 event with a size value ("SM", "MD", etc.) and a quantity value ("1", "2", etc.) for each separate variant. Could be good to generalize the tag and/or add an option for different prices on each variant, but all tags are only arrays of strings, no nested tags, at least from my understanding. The left curve option would just be to add an independent tag for each variant, but that can bloat the event pretty quickly, especially if there are other types of variants added, like colors.

[amunrarara]

If there's several tags that need to be associated with a specific variant however, like tying a specific size to a specific price for example, what's your thoughts there?

[gzuuus]

Regarding the variable products, some time ago I proposed a way to do this for NIP-15. The idea was to add a type tag to the product that can be <string, "simple" | "variable" | "variation">. In this way, if you want to create a variable product, you create the root or default product variation with type: variable, and then the variations are different product events with type: variation that point to the parent product with an a tag. This approach would provide all the expressivity needed to create variations without the overhead of embedding everything in variant tags. What do you think? You can read the proposal I made here. https://github.com/gzuuus/nips/blob/598682be747cd0a3b507ac7c87fc5821d89d1757/15.md#event-30018-create-or-update-a-product.
Quoting from there

type:This determination categorizes a product as either a simple product, a variable product, or a variation of a variable product. For example, a shirt sold in a single color is a simple product, while a shirt offered in multiple colors is a variable product with variations. To establish a link between a variable product and its variations, the variation product event should include an a tag that references the event coordinate of the corresponding variable product.

[amunrarara]

In this way, if you want to create a variable product, you create the root or default product variation with type: variable, and then the variations are different product events with type: variation that point to the parent product with an a tag.

That's an excellent idea. Thumbs up on my side.

[amunrarara]

Also from Vitor 7 minutes ago:

We could use kind:99? Is that used already?

[amunrarara]

...the variations are different product events with type: variation that point to the parent product with an a tag

@gzuuus Just confirming, each "variation" will have a unique "d" tag value?

Also, this would be a "required" tag I take it?

[gzuuus]

Yes, each variation should have an unique "d" tag. I think "d" works well as SKU

[ericfj2140]

Nostr is BTC agnostic, here we are requiring a form of BTC for payment proof... should Nostr marketplaces enforce this? I'm personally obviously pro Bitcoin and would encourage and prioritize this but "required" has me concerned

[amunrarara]

I'd also opt for this system being payment-agnostic.

[gzuuus]

Sorry, maybe I should be more clear. a required means a proof has to be provided, doesn't matter if its btc related or not. So if a merchant offers some sort of fiat gateway when the user pays, they should at least provide some confirmation that the payment was made, even if its just saying "payment was made".