Interesting. Muun should support lnurl-pay, it's so simple. I guess that means I should too, I'll give it a go this weekend.

It's actually a really great idea since the generated lnurl pay code could be reusable. No need to interact with the site and make new barcodes for each invoice. And you could receive donations without revealing your wallet custodian. Thank you!

600 sats \ 1 replies \ @jake 23 Sep

And you could receive donations without revealing your wallet custodian.

Are you thinking in this case that lnproxy would act as an lnurl-pay provider itself, and relay the request to the payee's lnurl-pay provider behind the scenes?

If so, wouldn't this remove the ability for the payee to confirm that the wrapped invoice is valid? In terms of Lightning Addresses (for simplicity), having ex. me@lnproxy.org -> me@me.com would mean that there's no way for the payee to confirm that nothing fishy is going on with the invoices generated for me@lnproxy.org, since they'd be provided directly to the payer by lnproxy.

To keep that ability for the payee to inspect the wrapped invoice, I'd think you'd need to have the payee's lnurl-pay provider call out to lnproxy, rather than the other way around. It's interesting to think about if something like this could exist as an lnurl sub-spec so that the expectations for both a proxy client and proxy provider could be codified 👀.

That's an excellent point. Without the ability to verify that the payment hashes match, you should not trust the proxy server.

But there's also not much point in using a proxy in that case.

I'll have to think more on this.

100 sats \ 0 replies \ @kale 22 Sep

Actually what I want to build is like stripe payment link. It's a no-code tool people has lightning address can generate link and sell anything.