LNURL-withdrawPOS flow

[theDavidCoen]

Pull request for blip regarding LNURL-withdrawPOS flow standard.

[cdecker]

Very nice @theDavidCoen, documenting this protocol is definitely overdue, so thanks for picking up the slack.

I went through and commented whenever something jumped at me, some of the comments are more pedantic than necesary so feel free to ignore, but I wanted to give concrete examples of how I'd written it (doesn't mean that mine would have been any more correct) :-)

[cdecker]

NFC in this case seems more like an example transport rather than an explicit limitation.

[cdecker]

Suggested change

	This bLIP serves to document what could be a reference flow for open source implementations of POS devices able to read LNURL-withdraw links via NFC,
	This bLIP serves to documents the flow for open source implementations of POS devices able to read LNURL-withdraw links via NFC,

Again, NFC seems more like a detail here, artificially limiting the applicability (links, QR codes, etc are just as valid as transports).

[cdecker]

better as compared to what?

[theDavidCoen]

Ehy @cdecker thanks a lot for your comments and suggestions!
It's my first PR here so I really appreciate your help.
I merged some of them and edited the text as well, however I have a couple of questions:

1. Lines 23-26, can you clarify what you mean with "NFC in this case seems more like an example transport rather than an explicit limitation." ?
2. Rationale - I documented the security concerns, can you take a look?
3. A Github related question since I'm a newbie: can you help me changing the number of the blip? I can change the number inside the text and of the .md but I'm not able to change the number of the folder.
   I believe the correct number should be blip16 since the PR is LNURL-withdrawPOS flow  #16 .

[cdecker]

Ciao @theDavidCoen.

1. It seems to me like there is no requirement to limit ourselves to MFC or qr codes, and that allowing other methods of transferring the LNurl details would be fine, so why explicitly limit yourself to NFC?

2. Will take a look 👍

3. That's more of a git question than GitHub specific, but the way you'd do it is using git mv oldname newname and then commit the changes

[theDavidCoen]

@cdecker sorry for the late reply.
Please note that this blip doesn't want to document LNURL protocol itself, but a specific flow for NFC payments using LNURL-withdraw.
As mentioned in the description, there are already implementations using a similar (or even identical) flow, and the goal is to have them and future solutions using a standard flow such as this one.

[GeorgeTsagk]

Isn't this spec heavily dependent on the LNURL specifications?

• Why is this a PR to the BLIPs repository? (and not a PR to fiatjaf/lnurl-rfc ?)
• If LNURL related specs were to be introduced within the namespace of BLIPs, shouldn't the whole set of LNURL specifications be migrated here? There is no exact definition of what the responsibilities of BLIPs are, but if we want to include anything LNURL related I believe the whole LNURL umbrella should be introduced for consistency.

[theDavidCoen]

@GeorgeTsagk thanks for your comment.
In regards to your questions:

1. This is a UX flow, not a new LNURL sub-protocol.
   In fact, it uses LUD 3 (but can use other LNURL-w sub-protocols).
2. I agree that LNURL specs should be also added here as a blip.

[lucasdcf]

Chiming in to agree with David that the LNURL specs could totally be a set of blips (one for each LUD)

[cdecker]

I'd like this, and the other LNURL specs, to be mirrored here, since they are being adopted by a large number of implementations, wallets and services, and are clearly part of the LN ecosystem. It'd serve as an acknowledgement and would facilitate finding them by developers looking for solutions to their problems.

Notice that in this repository we only perform stylistic and understandability checks, not discussions on the merits or design choices in order not to dissuade users from pursuing various solutions, as such there would be no barrier to mirroring LNURL, and you might get some feedback on whether the documentation is complete and understandable (I too sometimes take things as given, but they are only because I was present while they were discussed, and someone joining later might not have that context).

This is however completely up to the LNURL team to decide.