xpay BIP353 support#8467
Conversation
Signed-off-by: Rusty Russell <[email protected]>
139a344 to
6d50311
Compare
fetchinvoice is still good for detailed diagnostics and handling recurring invoices and alternate currencies, but this covers the "throw some sats" case well. Changelog-Added: JSON-RPC: `xpay` can now pay a simple offer directly, rather than requiring fetchinvoice first. Signed-off-by: Rusty Russell <[email protected]>
Changelog-Added: JSON-RPC: `xpay` can now directly pay a BIP353 address, like `₿[email protected]`. Signed-off-by: Rusty Russell <[email protected]>
6d50311 to
1145cbb
Compare
| "type": "string", | ||
| "description": [ | ||
| "bolt11 or bolt12 invoice, or a bolt12 (non-recursive) offer. If it's an offer, the invoice is fetch using `fetchinvoice` automatically." | ||
| "bolt11 or bolt12 invoice, a bolt12 (non-recursive) offer or a BIP353 name. If it's a bip353 name, an offer is fetched with `fetchbip353` if available. If it's an offer, the invoice is fetched using `fetchinvoice` automatically." |
|
|
||
| instructions = json_get_member(buf, result, "instructions"); | ||
| json_for_each_arr(i, t, instructions) { | ||
| offertok = json_get_member(buf, t, "offer"); |
There was a problem hiding this comment.
why are we iterating through the offers but only picking the very first one?
|
Nice! |
|
It's not working for me yet. Am I missing something? Obviously
|
you need to build with rust since |
|
@daywalker90 ah, thanks. Then I prefer to wait for a proper implementation in C or is this the new normal that we also have to build with rust? |
You don't have to but you will miss some functionality like this, a rest interface, a grpc interface, the wss-proxy, lsps. I'm not aware of any C implementation being planned for fetchbip353. |
|
@daywalker90 thanks, I've got it working now but I can't say I'm very happy with this rust complication for |
FTW.
And:
Closes #7632