1249 sats \ 4 replies \ @0330830bf9 13 Sep 2023 \ on: What are you working on this week? meta
Continuing work on what I discussed last week: #245900
Recap:

What
A lightning wallet that supports multiple NOSTR and LNURL sources so that you can aggregate your custodial accounts and non-custodial nodes and sprinkle in some automated rules.

Update
We've found that most services supporting LNurl-Withdraw don't do so in a reusable way.
Withdraw links time out (@SN), or the service itself doesn't have CORS configured for use with WebApps (have reached out to a few... some have fixed but others haven't).
This may limit this features utility largely to LNbits back-ends.
We've largely moved on to the Nostr RPC elements so that users will be able to more easily provide accounts to friends, family, clients and webapps without complex server configurations.

Feedback
How would you like to see a wallet use LNurl-Withdraw? As a spending source you use semi-regularly? A one-time voucher to sweep funds another account/node?
What else should we know about how to make the perfect Lightning wallet?
write
preview
10 sats \ 3 replies \ @k00b 13 Sep 2023
If our implementation is broken, please let us know. I'm always up for ways we can support interop.
reply
351 sats \ 2 replies \ @0330830bf9 14 Sep 2023
I wouldn't say it's broken as the spec does not say withdraw k1's must be reusable. But you could make the case they're more like vouchers than true withdrawal endpoints as implemented.
Actually the fact that we didn't have CORS issues with SN is an improvement over most other services. I found that as a CORS workaround some Lightning Address tools are proxying them through a back-end. That is not only unnecessary but doing so could normalize logging or MITM shenanigans.
Anyhow, SN would be a great service to demo this concept with. If you decide to disable the timeout on withdrawal k1s, such that a wallet can use them as a payment source, I'd gladly produce demo's flexing SN like so: https://lightning.video/017c91486137f82cc1300bcb2f7cc9a2c654300101e1ecbc82d642c46a24d564
reply
10 sats \ 1 reply \ @k00b 14 Sep 2023
IIRC My concern with replayable challenges was that they're ... replayable access to the funds of the wallet, e.g. I scan a QR over someone's shoulder.
It seems like there should be additional authentication around such a thing.
reply
351 sats \ 0 replies \ @0330830bf9 14 Sep 2023
That is a valid trade-off, though if that occurs someone could just as easily snipe it first.
To avoid accidental capture over Zoom etc, perhaps before rendering the user should click a warning or choose a voucher vs. persistence.
Once Lightning Pub is stable I hope to displace LNURL with Nostr methods so that everything can use keys.
reply