Absolutely. The algorithm’s job as I see it will simply be to facilitate a market between suppliers of resources and consumers of resources so the network maintains an optimal level of spare capacity.
That really shouldn’t need to be complicated or require human intervention.
I think RFC0057 is very different to how you expect things to work based on previous RFCs, e.g. farmers aren’t paid based on GETS, but on PUTS in their section, if I’m reading it correctly:
When a client pays to store or mutate data, the payment will be immediately be divided amongst farmers.
Though, as David has said, the current implementation is not expected to be perfect and there will be a lot of thinking & observation of test networks done before the final algorithm is designed.
If 1 SNT were received from a PUT, why couldn’t the rewards given out total 1 SNT (e.g. 0.85 to farmers, 0.05 to core devs, 0.1 to app devs)? Why would there need to be more received in store costs than given out in rewards?
I don’t think the need for a buffer is a fact.
What kind of event would cause everyone to stop putting data onto a successful and healthy global data network?
If there’s a drop in demand for storing data, the StoreCost & Farming Rewards need to drop. When this happens, it’ll trigger more uploading of data as it becomes cheaper. If you prevent the StoreCost & farming reward dropping when demand drops, you reduce the efficacy of the market that balances supply and demand of resources.
Even if short term dips in network activity became a thing, farmers would simply average the rewards out over time. I doubt they would cease farming because they had a bad hour if they can see their daily / weekly rewards are healthy.
Of course automating big uploads to take advantage of any short-term dips in StoreCost could likely be done, which would further reduce the likelihood of significant dips in demand for uploading to the network.
In my view, it just needs to be kept simple - demand and supply of resources should be kept in balance, and that doesn’t need a buffer. Hand-to-mouth is not a problem if there’s a constant, or regular flow of network usage.