You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 16, 2021. It is now read-only.
A farmer brought up the idea to allow farmers to announce a downtime interval to the network for for example updates, fixes... This is actually a good idea if you think about it, announcing a downtime interval to the network makes things more efficient and allows the bridge to know in advance when a user will go offline, adjusting mirroring strategies... accordingly.
The text was updated successfully, but these errors were encountered:
This is a "very" good idea, and one that I thought about regarding maintenance on my own farm.
For this action of notifying the network t time before it happened:
The network could have the opportunity to assess/cache the most valuable/likely-needed data from this node before it left the network. It will also be important to consider that node's bandwidth limitations. It might even give the network the ability to accept or reject the farmer's proposed time/date estimate based on the network's calculated ability to gracefully and probabilistically withstand that node's proposed downtime. The further away the date of the planned downtime, the more likely the network's ability to react compensatorily, and approve the downtime, thus reducing the penalty to that farmer.
That node could be rewarded or their downtime penalty could be reduced, for having let the network know in a timely manner. This could be linear, or logarithmic. This incentive is as opposed to just going down suddenly because your system can't handle what your node(s) is saying it can handle (cough cough ahem* is it hot in here?*). There could be a reward/penalty-reduction when the farmer meets/beats their downtime estimation. Or in other words, give visible incentive to keep downtime to a minimum.
The data regarding the success rate of the farmer to predict their downtime could be bundled into an existing metric, or a new metric could be created which bears the repercussions solely of the farmer's prediction success rate. The metrics could involve statistics such as TotalDownTime : PlannedDowntime vs UnexpectedDowntime
A farmer could have their TimelyNoticeBenefits reduced or eliminated upon u amount of subsequent unexpected downtime within a given month.
OR, it could just be a point system on a leaderboard that gave farmerJohn recognition for good behavior. (P.S. NEVER underestimate the power of the dark side the leaderboard!)
Summary: visible, comprehended incentive to remain UP, rewarding those farmers who give (timely?) notification to the network of their downtime before it happens. The statistics could be used to gauge the projected reliability of the given node, and therefore a measure of its value to the network.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
A farmer brought up the idea to allow farmers to announce a downtime interval to the network for for example updates, fixes... This is actually a good idea if you think about it, announcing a downtime interval to the network makes things more efficient and allows the bridge to know in advance when a user will go offline, adjusting mirroring strategies... accordingly.
The text was updated successfully, but these errors were encountered: