Tipping via LNURL-pay

[Overtorment]

https://github.com/btcontract/lnurl-rfc/blob/master/lnurl-pay.md

[takeeatback]

I'd like to add a 1 million sat bounty (.01 BTC) for anyone who gets this implemented in the backend as well as in the wallet. (generate tipping QR in wallet)

[Overtorment]

Plan:

• [ ] user should be able to choose public username. should be database key-value records like username_for_{userid} = {username} and username_{username} = {userid} for lookup and reverse lookup. should be an api call to claim username (uniq check should be in place), and fetch own username. should be covered by integration test.

• [ ] should be an endpoint for tipping. should render a QR code with a dynamic url endpoint so client can negotiate amount wia lnurl-pay. dynamic url should carry a tippin username. should be covered by integration test.

• [ ] lnurl-pay negotiation url. once amount is negotiated its trivial to issue an invoice for specified userid. issued invoice should have some kind of a flag that its a tippin invoice and should not be returned to client if its unpaid (otherwise user's tx list will be cluttered), either in json object or in bolt11 description.

• [ ] UI for bluewallet. option to claim or display username. option so share tippin url

• [ ] some kind of versioning required. perfect case is adding lndhub /ping endpoint to get version, so BW knows whether tippin is supported on this instance. hardcore approach would just be to probe a get-own-username route, and if string is returned then tipping is supported and BW can render tippin-related controls, if error - dont render it

• [ ] push notifications for each tip. the hard part. BW client explicitly subscribes to each paymenthash, so GC knows which paid paymenthash belongs to which token so GC can push message to that token. tippin happens outside BW, so BW doesnt know payment hash in advance. and when GC will receive a notification from LNDHUB about paymenthash paid it wont know which token should receive a push notification. the solution could be if client (BW) fetches own lndhub userid (NOT username), and subscribes it to all updates on GC, so GC has a relation token->lndhub userid. that way when GC received a notification that certain invocie was paid, and if there is an attached lndhub userid - send push to this associated token. so changes that are needed: when lndhub notifies GC about paymenthash paid attach a lndhub_userid to the payload. GC should be amended as well to accept this field in the payload and lookup this subscription and push (mind the openapi). table of relation token<->lndhub_userid should be added to GC. GC api call for such subscription should be created. BW should explicitly subscribe to GC. lndhub needs an api call to return own userid for authorized user.