zerologin VS luds

And this is someone else's implementation meant to help people who aren't good at implementing things from the spec: https://zerologin.co/

LNURL is the tech, https://zerologin.co/ makes it easy

Its really easy using zerologin https://zerologin.co/

If it is really only about auth maybe consider https://github.com/lnurl/luds/blob/luds/04.md LNURL Auth. But then your users should be able to understand the idea of private/public keys.

Independent solutions have also sprung up – notably, lnproxy, an invoice privacy tool (invoices are simply payment requests), and LNURL, a suite of tools for enabling communication between various Lightning applications and services over the web. So what’s a privacy-focused Bitcoiner to do, rely on the fledgling BOLT 12 specification or turn to one of these independent tools?

The technical specification is here: https://github.com/lnurl/luds/blob/luds/04.md

Thanks! yes, managed to set the static QR-code up via the LNURLp extension. How can I figure out if a wallet supports LNURL? I just tried sending myself via BlueWallet and it worked :) I've found this article saying "...it's been adopted in some of the most popular Lightning wallets including Zap, Phoenix, Breez, Blue Wallet and Wallet of Satoshi, as well as dozens of other apps."  - not sure how to interpret the table in Github though.

Since the inception of the lightning network and the development of the ln-url standard, the holy grail of "bank as a web app" is not only a reality but only 5 minutes of set up time and about 30$ of hosting costs away. This starter implements such an app. Authentication and Users are already there, and basic in- and out flow of purchasing power is taken care of. Users can authenticate themselves, deposit and withdraw up to 1000 sats. Whatever happens in between is up to the developer.

Could have been an LNURL payRequest. Unfortunately that does require a service provider, as someone has to be running a server to service the URL. You can host that yourself, of course, but that's way more complex than 99% of Lightning users will tolerate. Many will accept the risks of delegating the hosting out to a third party.

There is a nice article that describes how this feature works on the NFC chip. The URL it produces uses LUD03 and LUD17 from the LNURL spec. This diagram (source) also nicely explains how it works. In this case, the 'User with a smartphone' would be the merchant's point-of-sale device, and the web application would be the LNURL-withdraw server.

And here's specification: https://github.com/fiatjaf/lnurl-rfc