This can be a great idea, if its worked out in a correct way.In my eyes i see it more like this:A SNO can requests a planned maintenance. This has to happen X time in advance, given ample time for the node to drain its storage resources. The time in advance should depend on the amount of data that needs to be moved + a fixed value. During this 'Drain period' the node will not be able to create tokens for this SNO. In return the network will not give any penalties to the SNO reputation. When the SNO cancels the maintenance period or it auto-expires after a set X time ( This to prevent abuse ). The node will became available to the network and count towards the reputation of the SNO. ( Even if the node itself is still offline! ) If the node is operational, it will start as an empty node again! This will help as a incentive for the SNO's to keep there nodes running.There should also be a max. amount of scheduled maintenance per node possible. Any more will result in reputation loss for the SNO. Again this is against abuse of the system.This type of construction would allow any size of SNO to do major maintenance on there nodes and keep the network more stable ( less random node drops for maintenance ).
It does have a drawback, draining a node can create a high amount of recovery traffic. And this means we will need to take a look at the costs associated with this. It might cause a lowering in reward money of recovery traffic. Or a small fee required to put a node on planned maintenance.
This is just my 2cents.
I support Valentijn van Achte's idea!
I do support Valentijn van Achte's idea too! Very well explained.
(SNO's can already perform planned maintenance. Knock yourself out. But if we're talking about maintenance that results in data going offline with no consequences, then...)
This isn't a good idea.
Rewarding SNOs that contribute to data-availability with payment and reputation... and withholding those benefits from those that don't (e.g. are offline) is a good idea. It's simple, doesn't require trust of SNO's (like a promise to come back online later), and encourages behavior that helps the Storj network (like configs that don't go down for maintenance, or that perform it quickly).
A SNO with an offline node isn't helping the network, and shouldn't expect to maintain the same reputation as a SNO that stays online. And I'm not sure a preregistered-downtime system (like mentioned in other comments in this Idea) is something that Storj-as-a-company could endorse either. They're making availability claims to customers, and those claims can't be jeopardized by random SNO's that say "Pretty please believe me I'll be back later, trust me dude" . Storj has to start rebuilding as soon as they detect data is less durable than their guidelines.
TL;DR - Data durability should never depend on pinky-swear-promises from SNOs
You won't be notified about changes to this idea.