Add WebLN support

[Reckless-Satoshi]

Is your feature request related to a problem? Please describe. Using WebLN users can lock bonds and submit invoices with a click via a browser extension (e.g. Alby). These browser extensions are easily linked to the user LN node/wallet.

WebLN could also be potentially compatible with the Webview app that is WIP https://github.com/Reckless-Satoshi/robosats/pull/170 using react-native-webln by Hampus.

WebLN can be install as an npm package https://www.npmjs.com/package/webln

Additional context A short discussion with WebLN specification developers hints that WebLN might get confused with Hodl invoices (invoices where settling happens/doesn't happen at a later stage), some hacking might be needed or some proposal for improvement can be discussed. In any case, we should first confirm whether Alby (or other) browser extensions library work well on TOR enabled browsers (Tor Browser or Brave incofnito w/Tor).

This feature is eligible for developer compensation (pilot program) Currently awarding ⚡ 200,000 Sats

[KoalaSat]

Hi @Reckless-Satoshi I'm taking a look into this (first) issue.

I'm curious about the details of your discussion with the WebLN team. Also, I would like to understand if this work is just about integrating and testing the library so it can be used in future implementations or the idea is to make it work with the actual front-end.

[Reckless-Satoshi]

Hey @KoalaSat ,

Conversation was very succinct. I got the impression that WebLN browser plugins might not yet support "pending" payments. Therefore, not allowing the frontend to advance to the next stage of the trade pipeline. There might be some hack we can do around it, but it is largely unexplored.

The idea is to work on a branch and make it work on the actual frontend with the expectation of maybe finding a roadblock related to either 1) hodl invoices or 2) browser compatibility. If a roadblock exists, report back to webln devs with specifics of what is needed. There is a chance no roadblock exists at all. We should certainly be able to implement it with no issues for the submission of the buyer payout invoice and the withdrawal of rewards on the robot profile.

Another approach would be to simply work first on a demo to test whether hodl invoices would work or if hacking it is possible. I think it's about the same work or more that simply getting the work done by replacing code in frontend/src/components/TradeBox.js functions showQRInvoice() and showEscrowQRInvoice() .

Given that this is one of the oldests rewarded tasks and we have some more funds now, I will bump x2 the reward for this task. I am assigning you to the issue, mostly for reference if someone else sees the task in the panel. No pressure / commitment whatsoever :)

[KoalaSat]

Thanks @Reckless-Satoshi ! I'll work on some tests and share my thoughts here, I'll try to do it incrementally.

[KoalaSat]

This is the output of my spike, I modified the code on TradeBox.js as you said and managed to connect Alby to send the invoice we receive from the back-end. The library expects BOLT-11 format so every seems to work at this point.

However I found a problem at this point but not the one we expected, looks like dealing with testnet with the available WebLN add-ons is a little bit complicated.

• Alby: seems to have their own testnet so any invoice will fail
• KwH: It doesn't seem to support tesnet at all, or I couldn't find any doc about this
• Joule: Same

https://user-images.githubusercontent.com/111684255/185804771-72646c8a-fc07-49cb-a89e-da1530dc993e.mov

On the video above, you can see the error on the top. I couldn't get any logs because the error occurs inside the firefox add-on code, but it's really likely this error is because it's trying to run testnet invoices over mainnet.

I'm wondering it it might worth to directly test it with the main net.

[Reckless-Satoshi]

I'm surprised how quickly you have put this together :D

Indeed, an unexpected problem. It seems like the only way forward, as you mention, is to test on the mainnet platform. If you are using the "frontend development only" setup, it should be as easy as pointing Requestly to the mainnet site. Given that no real trade will take place, the unsafe site is probably fine. Creating an order with Explicit pricing method of 20K Sats with a 2% bond, the maker bond should be only 400 Sats, which is testnet-like risk :sweat_smile: (in case the locking works, just cancel the order)

[KoalaSat]

I'm surprised how quickly you have put this together :D

You did a great job with that setup.md file 😄

---

I already had this ready to check on mainnet, I was just waiting for your toughs about it. This is the workflow I have implemented using Alby.

1. The app checks if the webln library exists, if it does and it's the first time, the extension opens and ask for permissions

2. The extension receives the invoice and displays it:

3. Robosats automatically detects the invoice lock and just move forward to step 2, however the extension window keeps open and for the case of Alby the loading button keeps loading forever.

4. If the invoice expires or the user clicks on Cancel we got errors:

Looks like Robosats handles properly the transaction and everything seems to be working. The only problem is what you said, Alby doesn't manage this and just treat it as a failing invoice.

I tried to subscribe to the Promise of the sendPayment function but it doesn't seem to be triggered, looks like it's only called when the payment is done.

I never worked handling extensions from JS but if it would be possible (I don't think so), we would have to deal with all browsers 1 by 1.

I think dealing specifically with Alby is also a bad option, we have the same problem as with browsers, WebLN is a protocol.

I'll be happy to hear your suggestions or ideas about this

@Reckless-Satoshi - did the WebLN team suggest any specific workaround?

[Reckless-Satoshi]

As far as I can see the behavior is almost identical to any other Lightning Wallet, which is great! ( all of them have some quirks with hodl invoices as detailed in https://github.com/Reckless-Satoshi/robosats/issues/44)

The extension will never be able to know it is a hodl invoice and treat it differently. But it might suffice with the fact it shows a never ending spinner, as long as, it allows for several concurrent payments. For example, as a seller, you might want to lock a maker/taker bond and just next lock the trade escrow. Have you tested if it is possible to send a payment while the previous one is still ongoing? On a regular use the user will:

1. Accept paying the invoice in the pop up window
2. Wait for RoboSats frontend to advance to the next status.
3. Close the pop up window (with the spinner ongoing)
4. Proceed locking the next hodl invoice or submitting a payout invoice.

If this is possible, it basically does almost everything we could hope for. We should only document a bit how the experience is in http://learn.robosats.com/docs/wallets . Given that the frontend detects if WebLN is being used (is this the case?), we can also add in the app a small explainer paragraph on how to deal with the "forever spinner" (e.g. "once RoboSats status advances, close the pop up.")

If sending more than one payment at once is not possible, we could report on Alby to enable concurrent payments.

[KoalaSat]

I created the initial PR https://github.com/Reckless-Satoshi/robosats/pull/215 , happy to hear suggestions, for sure we might want to review the messages.

[Reckless-Satoshi]

PR merged. Thanks a lot @KoalaSat ! :rocket: