Introduce auto update and killswitch options on plugins

[Kukks]

This PR introduces 2 new features that can be toggled on installed plugins:

• Auto update - Once a plugin is installed you get the option to enable autoupdate, which will download and schedule the install for the next restart. A notification will tell you and give you an action to restart.
• Auto killswitch - Once a plugin is installed you get the option to enable the killswitch, where the plugin builder server can mark a specific version of a plugin as "Kill", and your instance will detect this and disable the plugin on the next restart, if the killswitch is enabled on the plugin.

Both are off by default.

[dennisreimann]

This requires another PR for the plugin builder, which isn't there yet, right?

I'm not sure if the kill switch is intuitive like this. I get the intention, that one wouldn't want to all of a sudden get rugged by a plugin being pulled, yet I think the behaviour is counterintuitive to the term (or at least my understanding of it). The way it is implemented right now, is more like an opt-in to accept that a plugin might be pulled — from a UX standpoint I think users might not get this feature and for plugin builders it is also frustrating, because users would have to activate it for it to have an effect.

[Kukks]

This requires another PR for the plugin builder, which isn't there yet, right?

I'm not sure if the kill switch is intuitive like this. I get the intention, that one wouldn't want to all of a sudden get rugged by a plugin being pulled, yet I think the behaviour is counterintuitive to the term (or at least my understanding of it). The way it is implemented right now, is more like an opt-in to accept that a plugin might be pulled — from a UX standpoint I think users might not get this feature and for plugin builders it is also frustrating, because users would have to activate it for it to have an effect.

Yes, haven't added that PR yet on plugin builder.

I agree, the use-case for the killswitch is really meant for killing specific vulnerable versions but is easily wide-scoped.

The UI is quite a draft until we narrow down the specifics on how to handle things. For example. currently to use any of these new features, one has to install the plugin, restart btcpay and then go back to the plugin list and toggle the feature.

[dennisreimann]

currently to use any of these new features, one has to install the plugin, restart btcpay and then go back to the plugin list and toggle the feature.

Ok, I think we could schedule updating those settings with the commands, like we already schedule other actions and run everything in one go on restart.

I agree, the use-case for the killswitch is really meant for killing specific vulnerable versions but is easily wide-scoped.

Imho we should narrow down the functionality to exactly this and not make it optional to the user. Otherwise a plugin dev might want to take down a vulnerable version, but can't as most users haven't opted-in. This would defeat the purpose.

If we decide it is worth the complexity to similarily keep this functionality, I'd rather think about how to give users the option to opt-in to running a vulnerable version after it has been "killed". Pro argument here might be that otherwise a plugin they rely upon might get removed and this way they'd still have a chance to use it, knowing it might not be safe to run it. (I've heard this story before, somewhere ...)

[Kukks]

currently to use any of these new features, one has to install the plugin, restart btcpay and then go back to the plugin list and toggle the feature.

Ok, I think we could schedule updating those settings with the commands, like we already schedule other actions and run everything in one go on restart.

I think this is more of a UI issue. we can mark plugins as auto update/killswitch on before they are even installed. the issue is when and where do we show these options?

I agree, the use-case for the killswitch is really meant for killing specific vulnerable versions but is easily wide-scoped.

Imho we should narrow down the functionality to exactly this and not make it optional to the user. Otherwise a plugin dev might want to take down a vulnerable version, but can't as most users haven't opted-in. This would defeat the purpose.

IMO killswitch should be on by default and auto-update off.

If we decide it is worth the complexity to similarily keep this functionality, I'd rather think about how to give users the option to opt-in to running a vulnerable version after it has been "killed". Pro argument here might be that otherwise a plugin they rely upon might get removed and this way they'd still have a chance to use it, knowing it might not be safe to run it. (I've heard this story before, somewhere ...)

kill switch should simply disable a plugin then. in the disabled plugin list, we should add an adjacent reason. So if a plugin was disabled via kill switch we can show the reason and a "re-enable and disable killswitch" action

[Kukks]

updated with

• better styling
• you can configure update/killswitch right after scheduling install
• if a plugin is disabled, a reason is shown
• you can re-enable disabled plugins
• default is killswitch on, auto update off
• notifications for both update and killswitch events

[dennisreimann]

tACK for what was testable so far. We should do some more user-testing once the RC is deployed — as far as I can tell this will also require updates for the plugin builder, which aren't present yet.

I think it would be also good to consider changing the update interval to something like every 6 hours or so:

services.AddScheduledTask<PluginUpdateFetcher>(TimeSpan.FromDays(1));