Update spec.md by calvadev · Pull Request #2 · GammaMarkets/market-spec

calvadev · 2025-02-20T08:24:34Z

Revised payment processing methods
Changed field values
Reorganized layout
Wording tweaks

- Revised payment processing methods - Changed field value - Reorganized layout

spec.md

ericfj2140

Leaving a comment to spur a more thorough review from the actual developers in the group. I don't see any issues with this- @calvadev has appropriately allowed for a third option to exist which allows for an async checkout without a service and defined it accordingly. Can we get some more eyes on this?

ericfj2140 · 2025-02-24T00:15:07Z

spec.md

also should this be named MIP-01.md instead of spec.md?

gzuuus

Looks good, but I think some concepts are a bit messed up

gzuuus · 2025-02-26T16:35:48Z

spec.md

 - Set via `payment_preference` tag in the merchant's kind `0` event
- Valid values: `manual | ecash | lud16` 
- Defaults to `manual` if not specified
+- Valid values: `service | ecash | lightning | bitcoin` 


I would keep manual rather than service, I think it better describes the method, if not i would keep both options

Yeah I was thinking of that as well. What do you think of manual, service, and direct as options?

I also saw that you had a discussion on Nostr about maybe supporting an array of values to specify the payment preference. That could be interesting as you could either define payment preference precedence and/or the preferred currency for that payment.

What do you think of manual, service, and direct as options?

Sounds good to me, and direct can be scoped, like direct:cashu or direct:zap or in case the w tags gets more adoption direct:monero where the scope should match the asset of the w tag. If no scope is specified, any of the direct methods can be used. wdyt?

as you could either define payment preference precedence and/or the preferred currency for that payment.

I havent understood this well, can you put an example of what you mean? The preference I imagine you are talking about the position of the items in the array right? but I did not understand the comment of the currencies.

In the case of relying on the position of the items in the array sounds good, and also will potentially solve payment methods that might conflict between then. Need to keep thinking about this and edge cases

What do you think of manual, service, and direct as options?

Sounds good to me, and direct can be scoped, like direct:cashu or direct:zap or in case the w tags gets more adoption direct:monero where the scope should match the asset of the w tag. If no scope is specified, any of the direct methods can be used. wdyt?

Ahh yeah, that's a good change since manual would always require a payment request and that's handled by the merchant to decide what they want, and service would just be the recommended app handler, so direct is all that needs extra specification

I havent understood this well, can you put an example of what you mean? The preference I imagine you are talking about the position of the items in the array right? but I did not understand the comment of the currencies.

Exactly that; and with the currency, asset type i guess would be more applicable, meaning ecash, lightning, monero, etc,

gzuuus · 2025-02-26T16:40:16Z

spec.md

+In this method, the buyer pays immediately and then sends their proof of payment to the merchant. The buyer waits for confirmation from the merchant and the order processing continues.

 ##### Manual Processing (merchant → buyer)
+In this method, the merchant manually initiates the payment by sending a payment request to the buyer. This requires that the merchant be online to process orders.


Typo? Should be This requires the merchant to be online to process orders.?

Both are grammatically correct, but it can be changed to be more clear if necessary.

gzuuus · 2025-02-26T16:44:09Z

spec.md

-In this mode, the merchant manually initiates the payment by sending a payment request to the buyer. This requires either:
- The merchant being online to process requests, or
- Having an automated system for processing payment requests, which can be run by the merchant or a service they rely on according to merchant preferences.
+In this method, the payment requests SHOULD be handled by the merchant's preferred service. This could be handled via an automated system for processing payment requests, which can be run by the merchant or a service they rely on according to merchant preferences.


If we make a distinction between "manual" and "service" I would remove "which can be run by the merchant" from the paragraph because in manual the merchant can have something running in his infra listening and responding. In case of a service based preference, the payment is initiated by the buyer with the help of the service. So I would keep manual for all payment requests initiated by the merchant (signed by the merchant) and the payment request initiated directly or by the buyer with the help of a service.

gzuuus · 2025-02-26T16:47:47Z

spec.md

  - Shipping information. `type`: 4
-
- Kind `17`: Payment receipts and verification



So we are going to finally remove the kind 17 of the communication flow? Doesn't it make sense to separate the receipt for accountability and better ux?

I generally think filtering at the tag level still provides a lot flexibility and UX (which is why I liked the idea of keeping all the order flow stuff as kind 14), but changing the receipt to kind 17 is cool with me too.

We could also set type 2 as a payment request and type 3 as the payment receipt instead of kind 17.

Type 1 - Order creation
Type 2 - Payment request
Type 3 - Payment Receipt
Type 4 - Order status updates
Type 5 - Shipping updates

Yes, here we would have to evaluate different things, like in case of historical review, where a merchant has already loads of orders, how easy would it be to parse all events of the same kind (decrypt and parse) to get just the receipts? I think the task would be huge at that level and maybe it would be worth keeping receipts in a different kind. As part of that, I'll also keep the market logic using type 16 instead of 14. So as we put in the spec, 14 for everything, 16 for ecommerce bussiness logic, and 17 receipts. wdyt?

Yes, here we would have to evaluate different things, like in case of historical review, where a merchant has already loads of orders, how easy would it be to parse all events of the same kind (decrypt and parse) to get just the receipts? I think the task would be huge at that level and maybe it would be worth keeping receipts in a different kind. As part of that, I'll also keep the market logic using type 16 instead of 14. So as we put in the spec, 14 for everything, 16 for ecommerce bussiness logic, and 17 receipts. wdyt?

Ah yeah, historical order tracking is a good case for a different kind. Sounds good to me!

gzuuus · 2025-02-26T16:50:04Z

spec.md

-  - Lightning format: `["payment", "lightning", "<bolt11-invoice or lud16>"]`
-  - Bitcoin format: `["payment", "bitcoin", "<btc-address>"]`
-  - eCash format: `["payment", "ecash", "<cashu-req>"]`
+  - Generic format: `["payment", "<medium>", "<medium-reference>", "<proof-of-payment>"]`


I would make it clearer that the last item in the array is not always necessary when we collapse payment req and receipt in the same message type.

gzuuus · 2025-02-26T16:51:14Z

spec.md

 2. Payment Processing:
-   - Manual mode provides more flexibility
-   - Automatic mode enables faster processing and convenience
+   - Direct and manual method provides more flexibility


Here should be just manual which is the one providing more flexibility, and direct is a faster way for processing and convenience

gzuuus · 2025-02-26T16:52:00Z

spec.md

- Valid values: `manual | ecash | lud16` 
- Defaults to `manual` if not specified
+- Valid values: `service | ecash | lightning | bitcoin` 
+- Defaults to `service` if not specified


Should default to manual right?

gzuuus

There are some changes to be done based in our convo

Update spec.md

f12d4d6

- Revised payment processing methods - Changed field value - Reorganized layout

calvadev mentioned this pull request Feb 20, 2025

[Top Builder 2025]: Shopstr PlebLab/Top-Builder-Season-2#8

Open

10 tasks

ericfj2140 reviewed Feb 23, 2025

View reviewed changes

spec.md Show resolved Hide resolved

ericfj2140 reviewed Feb 23, 2025

View reviewed changes

spec.md Outdated Show resolved Hide resolved

ericfj2140 reviewed Feb 23, 2025

View reviewed changes

Grammar fix

92d05a2

ericfj2140 reviewed Feb 24, 2025

View reviewed changes

spec.md

Copy link

ericfj2140 Feb 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also should this be named MIP-01.md instead of spec.md?

calvadev reacted with thumbs up emoji

Tag naming correction

0343bf6

gzuuus suggested changes Feb 26, 2025

View reviewed changes

gzuuus suggested changes Mar 17, 2025

View reviewed changes

		- Shipping information. `type`: 4

		- Kind `17`: Payment receipts and verification

Conversation

calvadev commented Feb 20, 2025

Uh oh!

Uh oh!

Uh oh!

ericfj2140 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gzuuus left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gzuuus Feb 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

calvadev Feb 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

calvadev Feb 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gzuuus left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

gzuuus Feb 27, 2025 •

edited

Loading

calvadev Feb 26, 2025 •

edited

Loading

calvadev Feb 27, 2025 •

edited

Loading