Closed Bosch-0 closed 2 years ago
Relevant reading for this page: https://medium.com/breez-technology/get-ready-for-a-fresh-breez-multiple-apps-one-node-optimal-ux-519c4daf2536
Breez and Greenlight agree on the fundamental virtue of user sovereignty, and we ensure it together. But there is still a division of labor. For example, Greenlight provides some handy services for nodes on their servers, like encrypted backups and watchtowers. Breez powers Greenlight with its LSP backend, ensuring seamless connectivity to the network and automatically managing channels. By integrating Greenlight, Breez can continue to provide the same services we always have and more with a better UX. It’s a fundamentally different, superior architecture.
Notes on the above article I made
I may be a little bias as I’ve been thinking about this with Zeus with its plans for a mobile run node later this year. We’ve discussed having multiple apps for different use cases similar to Breez so can see the value. But here is my thoughts, subject to change:
This is based on my belief that in the future, users will have more than one app that uses lightning. It could be the same app but different platforms (mobile + desktop). Or it could be different apps for the same, or even different, use cases (Breez for payments, BTCPay server for your store). I’m sure more use cases will become more apparent as the ecosystem expands. For either scenario, using locally run nodes with this multi-app paradigm requires a separate node to be run, and thus separate keys for each app. Running multiple nodes adds a lot of complexity, the two nodes could be out of sync across apps for example, and is an unnecessary use of resources. Managing multiple keys also makes key management more complicated. Adding friction between moving between apps also increases centralisation as users have a soft lock-in with app providers.
Backups on lightning are also a friction point for users, and I don’t have super strong thoughts around this atm with regards to Greenlight, but something you could do with this architecture is: say I lost access to my mobile app, I could use the desktop app (which has the same keys) and scan a QR code from my newly installed mobile app and recover it that way rather than re-enter my recovery phrase. This would be assuming that Greenlight is backing up the users channel states for them. With Greenlight, you can avoid these issues by using one set of keys and one (their) node across as many different apps as you want.
Here is example scenario – Say Zeus has a mobile payments app with a companion desktop app connected to a Greenlight node. Having these apps just acting as signers and not a node, they could both have a copy of the same keys, so I could fluidly switch between and use both versions of the app to make payments. This could be applied to two different apps also. Having two apps with hot keys present though would increase your attack surface, so there is trade-offs to consider.
I liken the user experience of Greenlight to external signers (hardware wallets). When using my Trezor, I’m not locked into using Trezor suite. Contrast this with a lightning wallet using a local node my keys are intrinsically tied to that wallets local node. Moving to a new wallet would require a new node and thus new keys. Greenlight enables much similar interoperability as on-chain keys / wallets. Their are some caveats to this analogy though as these two scenarios would have vastly different security models (keys are hot in lightning), something to keep in mind.
As mentioned above, I’m sure more uses for separating nodes and keys will become more apparent as the ecosystem expands. Especially as things like LSPs and lightning wallet servers (Roy’s term used in his article for non liquidity services like backups) become more common place.
Relevant video to view - https://www.youtube.com/watch?v=jXjsxvuxByc
Moved from the now closed PR https://github.com/BitcoinDesign/Guide/pull/568. Will be making some follow up changes based on the below discussion.
@sbddesign
My reply to this feedback