Sovbiz patch 1 #1703
Sovbiz patch 1 #1703
Conversation
General Updates from our call containing a overview to the other parts of the process (payment, shipping order communication, general checkout procedure) Small outline for the Payment flow
|
It shouldn't use kind 14 directly. It should use a new kind just for for this. We already have kind 15 for images on DMs, so orders could be 16, maybe? |
|
Cheers @vitorpamplona , There's been a larger thread happening over on a fork, if you're interested in reading: https://github.com/gzuuus/nips/blob/7d59ffe1e81bb0bedd64752f34298118c6e57ce6/XX.md I'm curious about kind 15. That's the kind used for a NIP-17 rumor that includes an image? What's the thinkin' there with using a specific kind for "message that includes an image". Are there other specific kinds for different message types? I don't see 'em on the NIP-17 spec. |
|
PR is here for kind 15: #1537 This kind has been used by 0xchat of over a year now and we just integrated into Amethyst. The key part is that most chat clients will never implement orders (or images). So, keeping the kinds separate helps them make sure they can ignore a message instead of just showing an empty or unreadable message to the user. |
|
The other way to do this is to keep everything you need to run in the content and the tags are just extra information. For instance, on 2, you can do something like: {
"kind": 14,
"tags": [
["p", "<buyer-pubkey>"],
["subject", "order-payment"],
["order", "<order-id>"],
["amount", "<total-amount>", "<currency>"],
["payment", "lightning", "<bolt11-invoice>"],
["payment", "bitcoin", "<btc-address>"],
["expiry", "<unix-timestamp>"]
],
"content": "Your order <order-id> with items <item1, item2, item3> has been received.
Your total is <amount>. Please pay lightning:<bolt11-invoice - same as in the tag>
or send XXX BTC to <btc-address - same as in the tag> to complete the transaction.
This offer expires in <expiry>."
}In this case, the app doesn't need to support any of the tags to show the information to the user. And the user can pay the invoice externally if needed. The tags just help the app offer additional information. |
|
To me, it is either kind 14 with the complete description in ".content" for humans and all tags helpful but optional to understanding the message OR a new kind if you require clients to parse the tags to make sense of the message and help the user go through the order. |
| } | ||
| ``` | ||
|
|
||
| ### Product Draft (Kind: 30403) |
There was a problem hiding this comment.
No need for a new kind here you can just use: https://github.com/nostr-protocol/nips/blob/master/37.md
| "kind": 14, | ||
| "tags": [ | ||
| ["p", "<merchant-pubkey>"], | ||
| ["subject", "order-info"], |
There was a problem hiding this comment.
subject is displayed as a title of the message, like the subject of an email. If "order-info" is a code that might not be human friendly, it might be better to choose a better tag name.
| ["order", "<order-id>"], | ||
| ["item", "<product-id>", "<quantity>"], | ||
| ["item", "<product-id>", "<quantity>"], // Multiple items possible | ||
| ["shipping", "<shipping-option-id>"], |
There was a problem hiding this comment.
Need a standard on how to write this shipping info.
| "content": "Payment details provided by merchant's payment server." | ||
| } | ||
| ``` | ||
| 4. Payment Receipt (buyer → merchant) (subject "order-receipt") |
There was a problem hiding this comment.
Shouldn't receipts be a kind on its own? This is the only message that is not a "temporary" update. I can forsee users wanting to see a list of all of their purchases. It would be nice to have a separate kind so that there is no need to parse all DMs to find all receipts.
No description provided.