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!
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 👀.
reply
What do you think about integrating into a bridge server so that me@me.com would first access the lnproxy api to hide the @me.com public key? Then the owner of me.com could trust the bridge server code they're running to make sure that the payment hashes always match and the "max fees" don't change.
reply
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.
reply
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.
reply