10 sats \ 3 replies \ @k00b 13 Sep 2023 \ parent \ on: What are you working on this week? meta
If our implementation is broken, please let us know. I'm always up for ways we can support interop.
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
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
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