📅 Original date posted:2019-01-21
📝 Original message:
Francis Pouliot <francis at satoshiportal.com> writes:
> Here is how I picture the ux issues taking place.
>
> 1. User goes on my app to buy Bitcoin with fiat, and opts to be paid out
> via LN rather than on-chain BTC.
> 2. My app will tell him: "make an invoice with the following: msatoshi,
> description.
> 3. He will go in his wallet and type msatoshi, description.
> 4. It's likey he won't pay too much attention, make a typo in
> description, leave it blank, write his own description, etc.
> 5. When my app tries to pay, we of course have to decode his bolt11
> first.
> 6. We have to have some logic that will compare the "h" or "d" that we
> instructed him to create and the "h" or "d" that we got from the decoded
> bolt 11 (which is an extra hassle for devs)
> 7. In the cases there they are not the same, we need to instruct the
> user to create a new bolt 11 invoice because the one he created was not
> correct.
Yes, there's a missing "give me an invoice" API for this kind of push
payment. yalls.org has the same problem: there's a clumsy API where you
give them an invoice and it pays it if you have that much.
lninv: URL? Description, min and max amounts, submission URL? Ideally
the browser would reach out to the wallet to get an invoice and do the
submission itself (preserving sessions, cookies, etc) but I'm not sure
how that part of the stack works?
There was talk of something similar in Adelaide, but I hadn't
appreciated the concrete problem at the time :(
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:53:58
in reply to nevent1q…zagh
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:53:58Event JSON
{
"id": "66501bd17afd854ce473503e33787d8757814a6933e798e037899a1469a13b99",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315238,
"kind": 1,
"tags": [
[
"e",
"519a7a8c86eac72a23dc644543eb562443536845963ecffa2a6e73592013b70b",
"",
"root"
],
[
"e",
"a6d38622be31283829502a3b36a7e91a0dc7bf56a39cc9950e3207ca413fef64",
"",
"reply"
],
[
"p",
"c598379bb0bfce927892213b187cbd1fd084b9b90615a2ade2ff4a80da293447"
]
],
"content": "📅 Original date posted:2019-01-21\n📝 Original message:\nFrancis Pouliot \u003cfrancis at satoshiportal.com\u003e writes:\n\u003e Here is how I picture the ux issues taking place.\n\u003e\n\u003e 1. User goes on my app to buy Bitcoin with fiat, and opts to be paid out\n\u003e via LN rather than on-chain BTC.\n\u003e 2. My app will tell him: \"make an invoice with the following: msatoshi,\n\u003e description.\n\u003e 3. He will go in his wallet and type msatoshi, description.\n\u003e 4. It's likey he won't pay too much attention, make a typo in\n\u003e description, leave it blank, write his own description, etc.\n\u003e 5. When my app tries to pay, we of course have to decode his bolt11\n\u003e first.\n\u003e 6. We have to have some logic that will compare the \"h\" or \"d\" that we\n\u003e instructed him to create and the \"h\" or \"d\" that we got from the decoded\n\u003e bolt 11 (which is an extra hassle for devs)\n\u003e 7. In the cases there they are not the same, we need to instruct the\n\u003e user to create a new bolt 11 invoice because the one he created was not\n\u003e correct.\n\nYes, there's a missing \"give me an invoice\" API for this kind of push\npayment. yalls.org has the same problem: there's a clumsy API where you\ngive them an invoice and it pays it if you have that much.\n\nlninv: URL? Description, min and max amounts, submission URL? Ideally\nthe browser would reach out to the wallet to get an invoice and do the\nsubmission itself (preserving sessions, cookies, etc) but I'm not sure\nhow that part of the stack works?\n\nThere was talk of something similar in Adelaide, but I hadn't\nappreciated the concrete problem at the time :(\n\nCheers,\nRusty.",
"sig": "9d15801a4032fe6c46a52b7b12e14843a0813f775be046549c31ecb0763b5f236ad09598896567f370c214d55889626d37eaafede7eb69d54ff0a49de7ed2357"
}