Nice – excited to see how the deep linking experience is now. I tapped an invoice on my phone the other day and realized I couldn't select Mutiny, likely because I had it installed as a PWA. Looking forward to trying this out! ⚡️🙌

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 👀.

Jake from Mash here. Great question – thank you for the feedback! 🙌

We're building Mash to be accessible for everyone (from Lightning enthusiasts to non-technical pre-coiners), aiming to provide the best user experience possible (more than scanning QR codes); to enable this securely, we need users to log in. That being said, we're actively thinking about this and other Lightning-native experiences on our end (like lnurl-auth to make logging in a little easier for Lightning-savvy desktop users). ⚡️