Nostr Web Client

The original Lightning App we built had auto updates (using Electron‘s autoUpdater). This was often criticized at the time, which is understandable since lightning network was still new in 2018 and many users came with concepts and best practices of bitcoin core, where updates might change the consensus rules. But lightning is vastly more complex than the base chain. The whole premise of scaling in layers is that lightning can be more complex, take bigger risks and change quicker. While most lightning deployments are server based and do not use an app wrapper, it may be worth exploring an opt-in auto-update mechanism for node runners. This way folks who just want to set and forget their node can at least get the latest security updates.

StoneCodlHodl 💎👊 1y ago

But doesn't auto update remove the node runners "VOTE"?

The ONLY way I would advocate this, is if all new feature enablement required enablement (consent/vote) which is also NOT enableable by the VERY SAME auto updater.

This is an impossible task on a general propose OS and computing platform. Huge risks here with things like Umbrel and Statr9 which centralize enablement powers to a few. Short of a TRULY open source code base and benevolent PR merges.

Bitcoin does this through a community driven BIP process. These one click Node companies/ orgs aren't structured this way. They are also, move fast, break shit in (good?) spirit types.

Never forget Roger Ver used to have sway - but node consensus isolated his ideas. It's HIGHLY likely we must all vote again, and isolate those with grand ideas.

Reply to this note

Please Login to reply.

Discussion

tank 1y ago

Good points. I don’t have a good answer. It’s all trade-offs in the end. Any auto-update feature should be opt-in though to mitigate deviations from the bolt spec.