search

lnurl / luds

lnurl specifications
596 stars 140 forks source link

Addition of Reverse Authentication to LUD-18.md #240

Open nerdyrugbyguy opened 1 year ago

nerdyrugbyguy commented 1 year ago

Added lud16 and revauth to payer data provided by wallet. Added revauth to response provided by server. Added commentary about use cases.

augustresende commented 1 year ago

I think you should create a new LUD referring to the existing LUD-18, this keeps easier to track wallets/entities support.

fiatjaf commented 1 year ago

Please update the PR title to reflect what it is really about.

But I don't get this, is it just an idea? Is anyone doing this?

My impression is that there isn't much understanding about LUD-18 among services and wallets in the wild to make it worth adding anything here at this point.

Maybe when the basic LUD-18 features start to be used more we can invite more people to the discussion and see if anyone is excited to implement new fields.

Meanwhile, people should be free to add new fields to their implementations -- with the caveat that they aren't expected to find much interoperability and support for them.

augustresende commented 1 year ago

Please update the PR title to reflect what it is really about.

But I don't get this, is it just an idea? Is anyone doing this?

My impression is that there isn't much understanding about LUD-18 among services and wallets in the wild to make it worth adding anything here at this point.

Maybe when the basic LUD-18 features start to be used more we can invite more people to the discussion and see if anyone is excited to implement new fields.

Meanwhile, people should be free to add new fields to their implementations -- with the caveat that they aren't expected to find much interoperability and support for them.

Sometimes I see a lot of good ideas to improve but it appears to lack a bit of adoption incentives. Other protocols/businesses have some organizations that attest if implementation is compatible, with a brand/badge or something like that. LNURL should have at least one contact of wallet/service manager, or some mailing-list so everyone knows that something new is being proposed.

nerdyrugbyguy commented 1 year ago

I updated the PR title. This is just an idea without any implementation. My initial goal was to match the convenience of credit card autopay with the ability to fall back to an email based workflow. Should be possible for a wallet to be designed around LUD-16 and Email addresses so that user doesn't need to know whether or not the other party even has bitcoin or only has email.

I can re-write to be a new LUD that references LUD-18. Does that mean a new LUD number needs to be assigned? I can also remove the part where the service signs K1 because the service merely needs to provide the linking key like NIP-05 to complete the reverse auth.

Agreed that formalizing a LUD like this is pointless until there is more adoption of the preceding LUDs. Is there a way to preserve a working copy for reference and potential future implementation?