search

BitcoinDesign / Meta

Discussions around the processes and coordination of the Bitcoin Design Community
203 stars 20 forks source link

Lightning Browser Extension Design Call #1 #132

Closed johnsBeharry closed 3 years ago

johnsBeharry commented 3 years ago 
Date: 2021-08-16
Time: 1:00pm
Timezone: UTC
Duration: 1h
UTCTime: 2021-08-16 13:00 UTC

Announcing the second call with Lightning Browser Extension (collabaration #113)! Join in to learn about Lightning payments in the browser, and the alpha launch plans.

Agenda

  1. Demo
  2. Developer update
  3. Design review
  4. Alpha release planning

Check your timezone

https://everytimezone.com/s/aba9d2fb

Join the call

https://meet.jit.si/bitcoindesign

Calendar invite

Subscribe to the Bitcoin Design Events Calendar to always know when we're having calls and workshops.

moneyball commented 3 years ago

I see a couple of technical design options which would impact UX.

  1. Run a LN node as an app on the computer with the browser (eg your laptop) or on a remote computer that the user controls (eg a rpi). A browser extension is a relatively simple remote control to that LN node.
  2. Run a LN node (the LN state machine and key signing) inside a browser extension (eg using the modular LDK). A proxy server, which could be a 3rd party, would maintain LN TCP connections with peers, and would communicate with the browser extension via websockets.

Option 2 has the advantage of not requiring a user to install and operate a LN node on a computer. Option 1 has the advantage of better privacy as a 3rd party trusted server isn't needed to send/receive LN p2p messages. Both options are non-custodial.

Are each of these options being considered and discussed in terms of impact on UX design?

johnsBeharry commented 3 years ago

Hey @moneyball on today's call we briefly touched on this topic but it seems like its something that needs a call of its on. We'll be discussing it on next weeks call if you'd like to join.

TLDR; Extension in the short term focuses on the application layer and encouraging experimentation with bitcoin payments in the browser. Long term, having more accessible non-custodial "connectors". Current connectors are 1. remote controlled node (lnd), 3. shared channels, via lndhub (custodial).

The extension is focused on the application, payment and allowance experience. It's using no. 1 for now, as well as a 3rd option which is to use custodial services like LNDHub for burner accounts as a quick start for folks in the design community who aren't running their own nodes.

How might we get designers and frontend devs in the community collaborating and experimenting with payment UX cheaply (in terms of time, and knowledge). This relies a lot on the work by the joule team made on their extension as well as WebLN.

Since there is still development necessary for LDK to run in the browser, we can't be sure about all the UX challenges we'd face. Having ldk wasm and understanding constraints present across browsers is going to be quite a bit of work. You named one issue with TCP/messaging, but certainly there are others wrt storage limitations, access to the file system, backups, uptime, background notifications, that also need to be looked into. I'm very excited about seeing what this could unlock though.

Channel management/liquidity is also one thing to take into consideration. I believe since this use case focuses on paying on the web there may not need to be much incoming liquidity locked up with the channel partner, but at some point when the funds are depleted how is the wallet recharged?

johnsBeharry commented 3 years ago

There's no BitcoinTV or YouTube channel setup for this project yet so just going to post a Dropbox link of the session recording.

https://www.dropbox.com/s/2yaxm8oma5hzhrb/lbe-call-1.mp4?dl=0