That would be just a fork, and I doubt that many people would adhere to it right now.
But yes, in 50 years who knows? Maybe decentralization will be an ideal of the past and we’ll happily accept a new Bitcoin controlled by gouvernements.
But then there will be also a safe network controlled by gouvernements.
Bleak prospects for the future.
There will certainly be state-controlled safe networks. The Chinese will make their own safe nets, the Arabs will make their own nets, I will not be surprised if the big corporations have their own to…
Agreed. Over time it will splinter into various islands, corporate and government controlled. Imagine the Chinese version where to login your private key needs to be uploaded and registered with the government. Terrifying possibilities for a true panopticon…
Or all their devices will have a vault installed to use the free resource and to be able to store all the information in their safe network and the state to have access to it. No local storage, no personal space…
And then the 5 eyes realize this is their dream: strong encryption between people, but government access on demand, with legal “protections” of course 
. My fear is all of this “hate speech” nonsense and “its to protect the children” speak, regulations could pressure people into one of these buckets. The stuff of nightmares right there
This only shows how little people value freedom - far more important is a nice apartment and a well-paid job. As long as China is well economically and people get a good life there will be no change of government…
with food, comfort, and access to sex, most can’t be bothered to fight on principle.
+1 to that.
I’d like to see a decent bonus (discuss decent) paid to all staff (and past staff who left without rancour) once we reach some threshold (discuss) after launch of Fleming and listing on another couple of exchanges.
EDIT — Ok I wrote this before I read
lots to catch up on in this thread
My feeling is the reason for having a storecost and reward is not clear enough and this is leading to further confusion about other things like initial price for upload and how fast to mint new coins. Once we clarify the reason for storecost and rewards existing in the first place then the rest becomes much simpler.
It seems the current belief is storecost is payment for service and reward is a subsidy on top of that to further motivate farmers (to maximize growth). This approach seems to imply certain properties like: all rewards eventually end up being distributed to users, payments are only distributed to farmers and never return to the network, reward should be issued at some particular rate, payment will go direct to farmers rather than shared etc.
I’m not really in favor of that idea of the economy (I can get behind it but to me it seems illogical).
A brief historical aside: Bitcoin does not use fee as payment for service. And it would be absurd to do that. A tx in block 605 would overall be stored for slightly longer than a tx in block 606, so should the earlier tx pay slightly more? No. This is not just saying ‘bitcoin does not work as fee for service’, it’s saying ‘bitcoin should not work as fee for service’. There is no way to know the future amount of service required to secure that tx so there’s no way to pay now for that future work (a debatable point for sure; to argue against myself we saw in another thread a 10x decrease in storage cost every 10 years means permanent storage always approaches 5x the initial annual cost… so sometimes we actually can estimate the ‘cost forever’ based on the ‘cost now’).
Transaction fees in bitcoin are only used to prioritize which transactions to commit to the network. This prioritization mechanism only gets used when the rate limit is active (ie more than 1 MB of txs per 10 minutes is happening). If there’s no stress and no need for a rate limit then all transactions are accepted.
We can debate why bitcoin may or may not be a good model for our situation, but I think it’s a good example for why tx fees even exist in the first place. Fees are a way to decide how to use limited network resources. Storecost is a prioritization mechanism. I’ve said in the past that storecost is a rate limit, but perhaps it’s more accurate to say storecost is a prioritization mechanism (that operates when a rate limit is active). So storecost should be extremely cheap if the network is not stressed (no need to rate limit or prioritize, let’s maximize growth and accept everything). But when the network becomes stressed then there should be some restrictions until the stress is relieved, and the restriction means there needs to be a way to decide what is accepted to the network and what isn’t. That’s why we have a storecost. It’s not a payment for service.
With that bit of ideology on the table, we can ask ‘why have rewards’? Can we have a successful network without rewards? (Likewise we should ask can we have a successful network without storecost but I think the previous paragraph demonstrates the need for storecost). It feels like we can’t go without rewards because if we have a storecost then we need a way to pay that storecost. The reward is what allows people to pay the storecost.
To me it makes sense that we want as many people to have access to rewards as possible so they can also pay the storecost (and other reasons but I’m just looking at the core of the logical reasons here). Not everyone is in a position to be rewarded early on (didn’t know about it, didn’t have resources available, didn’t understand it, ignored it, hated it, whatever reason). This means that rewards must be spread out over time if reward is going to be useful as a way for many people to pay their storecost. How much time should it be spread over? Hard to say! To argue against myself again, we should also consider there are other ways to get tokens than the reward mechanism (eg exchanges, gifting) so maybe focusing too much on the single core logical reason is not especially helpful?
But the point I’m trying to make is that reward is not an additional subsidy for providing a service. Reward is the way that data flow is opened up and improved. If storecost is a kind of ‘quality assurance process’ then reward acts as a kind of ‘conveyor belt flowing into that QA process’. We can probably simplify and say: rewards enable network growth. The network grows when useful new data arrives (reward facilitates the storecost for new data) and when new farmers arrive (reward motivates participation and permanence). I’ve said in the past that rewards are to ensure permanence, I still think that’s the main purpose of rewards, and treating rewards with that purpose implies something about how fast to issue them (permanence and growth are very closely related imo).
These are what I feel to be concrete aspects that can be taken further into a working mechanism. Measure stress. Respond to increased stress with storecost. Measure participation. Respond to negative changes in participation with rewards.
I feel an economy based on a paradigm of payment for service is too risky, too much safety margin required, too fragile, too rigid.
The priority for network activity might be 1. join/relocation GETs 2. client GETs 3. client PUTs. This is because node membership is critical to network stability and security so must happen first, client GET is the most popular and cheapest and newbie and public-facing and end-goal function of the network (data is only permanent if you can fetch it so fetching is the key function for determining permanence), client PUT is a one-time event so is not as time-critical as the other two and depletes spare resources so is the cause of stress. Storecost as payment for service means farmers would say PUT is the most important operation, which to me seems very backward to the majority of participants on the network.
I haven’t responded directly to any prior posts because I feel the conversation has been based on suboptimal economic assumptions. Just wanted to throw my perhaps minority perhaps unpopular perhaps unwelcome ideas in here because it feels in the spirit of a brainstorm 
To be more concrete on what I feel about the rate of new coins arriving, it depends on measuring and responding to participation rates.
To me the best way to do that is using a deterministic cache to measure the degree of redundancy (allowing any amount of redundancy, minimum 8 copies, but no upper limit on cached copies). Set a strict minimum redundancy (eg 8 copies), then target some higher redundancy than that (eg 15 copies) as the point where reward expenditure pays out from network wallets at the same rate that storecost expenditure comes into network wallets. Variation from this break-even point workload leads to higher or lower reward rates.
Still brainstorming
Yes, that would be wrong indeed. The payment to farmers is really to ensure the network has enough resource to handle the data.
It’s interesting when folk say to us, store data forever, so pay once store forever, you are crazy, but that is exactly what bitcoin does. Still, its data is limited (really) to currency transactions. (there is some space for small bits of data etc.).
So if we take data (and assume we have DBC, so no currency transaction data, except perhaps a spent bank) our storecost is similar to a bitcoin transactin fee. It’s what the network requires you to pay to handle stress (as you say).
Just as higher transactions hopefully encourage more miners to help with bitcoin stress with us the same happens with farmers (earners ). Like bitcoin, we don’t want them to go away too much and we want the resource (hashpower or storage) to continually increase along with the data, over time.
I wonder, perhaps it’s more like a constant balance, it tips both ways to encourage new resource or not encourage it, perhaps even discourage it. That is from an earners perspective, but from a client perspective it’s cheap when not under stress and gets more expensive as it is stressed, so I can see that rate limit from the client side and from the earner side the reward/payment being more a business decision (like miners).
Perhaps it’s increasing rewards enables accelerated network growth but stable payments are a sign of a stable network (slow growth). (taking account of disks being cheaper over time etc.)
I Am not sure @mav if you mean rewards as in the 85% the network has to pay out or the normal client pays → earners get paid reward?
The balance of clients paying for resources is a bit unhinged in early days as the network supplements the client payments. So it looks like you can store say 1Gb for 1safecoin, but you only think that because the network paid an extra 1 safecoin to the earner (from that 85/%), so the balance is wrong there (IMO).
Just to remind you that inflation should not be considered only in the context of 1 closed system. Our Safe Network will exist (most likely) in a world with many Safe Networks that will rely on different economic models to attract earners. Inflation is our tool with which we will be able to compete with other networks on an economic basis.
I find the idea of rapidly dispersing the supply interesting, but I also see that there would be a massive negative reaction from many who have been waiting for launch to see a return on investments that such a change threatens to postpone or erase.
What if the compromise is that a reduced amount of Safe Network Tokens are minted thus countering the effect of the flood? (think of it as a burn… but they never existed)
Does the network really require 4.3 billion tokens?
I think perhaps, just maybe if the correct balance is struck everyone remains happy and the tokens could be set free rapidly without a mob setting off for Scotland.
This is an interesting concept. Here is another interesting concept. The block reward in the Bitcoin network is actually used to pay a racket. Why racketeering? Because the only ones who can attack the Bitcoin network are the farmers, because only they have the equipment for the SHA-256 algorithm.
So if we actually pay for protection, what would be the analogy in the Safe Network? Protection from whom? I think it’s from other Safe networks.
@dirvine Have you considered a network that is greedy with a mind/personality of it’s own? An integral economic player? What I mean is something like this:
We need focus on smooth start and to attract new people as much as possible. Bigger means more safe, more content, better token economy.
To ensure that I think it is worth to consider to maximise reward to 10 or more than each put, so every new user will be able to farm some tokens to play with in few days.( Even when it is risky.)
To compare with Bitcoin, miners got 8 times more for each block than today.
There was concept to use Healty Multiplayer fixed to total tokens already in circulation. Which is going down to 0 when 100% is near. And even 99,999% can be possible.
BTW. who is going to buy Fil to use their network in this early stage? It is quite cheap, but not prooven technology to store there sensitive data.
When I use the word reward as a noun/verb I mean the amount/event that contributes to the earnings of a farmer.
For rfc0057 I consider ‘reward’ to refer to ‘earning 2x storecost triggered by PUT’.
For rfc0012 I consider ‘reward’ to refer to ‘earning X safecoin triggered by GET’.
Always with the unspoken disclaimer ‘portioned by age / work / etc’.
It seems to me this topic is considering cashflow in a fairly direct relation like:
Storecost from uploader → Section elders agree on distribution to nodes → Pay node wallets (recorded now transferred later)
I am hoping for a more indirect way like:
Storecost from uploader → Pay into section wallet → General turbulence over time → Nodes earn from work related events (both upload and non-upload) paid from section wallet (recorded now transferred later).
So I see the section wallet as a kind of ‘buffer zone’ for tokens, sometimes increasing if a lot is uploaded, sometimes decreasing if a lot of new resources are needed. The different incoming and outgoing purposes of the section wallet are certainly related; it feels like in this topic the relation is mainly seen as a direct relation (uploading directly creates a payment to nodes), but in my view it’s better to think of it for the purpose of the thought experiment as an indirect relation (uploading facilitates payment to nodes but not directly from the upload itself).
Why is indirect better? We can make the indirect relation behave in a direct way if it’s appropriate to do that, but we cannot go the other way and make a direct relation behave in an indirect way. I don’t mind if whatever happens ends up looking like a direct payment, but I feel it would be a mistake to deliberately design reward flows in a direct and rigid way if a more flexible way is available. I would not want to do YAGNI (You Ain’t Gonna Need It), but this does not feel like one of those situations to me.
I guess most people would be happy with a single function distribute_upload_fee_to_adults. I would prefer to see it as two functions send_upload_fee_to_section_wallet and send_reward_from_section_wallet_to_adults. If we end up choosing to trigger the second function at the time of uploading we get the same effect as the single function, and that’s ok. But if we choose to trigger the second function when something else happens, we have an easy way to accommodate that behavior. The quantity for ‘upload fee’ and ‘reward’ is more easily decoupled if we want that (as a single function it’s hard to see it as anything other than closely coupled). My point is the flexibility of two functions seems essential for the thought experiment, even if in code we may not end up using that exact flexible structure.
Looking further at how I conceptualize network stress.
Storecost addresses the immediate symptoms of network stress (reducing upload rate; like taking paracetamol for a headache), reward addresses the longer term underlying solution to network stress (increasing resources; like hydrating, eating healthy food, staying fit, stretching and strengthening etc to prevent future headaches, these take time).
Uploads being the source of reward is contradictory in this way of thinking. Upload is the headache, and reward is the source of sustainability, so to link them with ‘reward on upload’ we kinda say ‘you must have a headache to be sustainable’. Maybe this is our form of hendoku iyaku?
But I want to extend the definition of stress. Stress is currently seen only as ‘too much upload leading to not enough storage space’. But stress could also include ‘too little amount of reward leading to not enough new resources’. If there’s not enough reward then it may be difficult to get more resources when needed, and this adds stress to the network.
If all tokens are in the hands of users it’s up to the uploaders to fix the problem of ‘too little amount of reward’.
If I see the storecost rising I would deduce the network is running low on storage, and I have only two choices, both seem poor:
I feel like sections always having some reward on hand is a useful feature for addressing the underlying reason for stress. It’s been said by others that the section having too many tokens is a risk (I agree) but it seems to me there’s also a risk if the section has too few tokens.
I prefer to see storecost used to manage the rate of new data, and rewards used separately to manage the rate of new storage. Using storecost to manage new storage seems strange to me.
I fear if I write too much I will overstate my case. I’m not especially against the rfc0057 type economy with rewards directly connected to PUTs, I think it would work ok. But I do feel it would be a shame to exclude the idea of separating storecost / reward. Separating the two really creates a lot of additional space in the brainstorm.
I always held the impression that the two would be decoupled ( storecost / rewards ).
Not sure why or when I conceived that idea though, its been a long trek.
I think you are correct in thinking they should be separate, even if some is essentially paid out immediately.
It may be seen as a risk having a section with funds , but IMHO if we can’t securely guard those funds, we failed rather spectacularly.
I agree @mav I have 2 overriding things in my mind and current focus.
2 is more subtle, but with users data, we have a strong design I think. So all data mutations are signed by client/owner (we are hopefully removing the word client from our code, it’s just keys.
So kinda like OwnerAUthority or a policy on the data allows some key(s) to mutate.
Then NetworkAuthorityis relegated to a notary function only. So it can noterise data changes, but not carry them out. This allows data to be published at any stage and also prevents folk form rewriting their own history (where a client could publish different content to alter history, causing conflicts and all the resolution we would need there).
This is all to let you know where my head is, so not 100% related to this convo but hopefully helps you see where I am coming from. BTW this is a valuable session to have on rewards, much appreciated and I think we can find a great solution.
Is there this still capability style? I hope so because it seemed such a bonus when this shifted and so much of Jim’s excellent UX design followed from this and I think depends on it.
Have any of the recent changes impacted on the capabilities of the Safe capability approach?
No need to go into great detail, just no, or maybe but xyz or, yes and we’re working on doing pqr etc
There is, at least in LSEQ, it’s the policy part. We are looking at Map doing the same now. I have not been so involved in the policy work, @bochaco really lead the way here, but I am 100% behind the capability-based design. At the moment I am trying to clear up Authorities and get that part really concrete. Then getting strong guarnatees on data consistency (that’s going well) and finally the capablitities “model”. The reason for this path (for me) is to ensure we know the “rules” of data changes that are crypto secure and guaranteed consistent. Then we see what we can do with capabliities given those constraints.
I feel that way we don’t fall into traps of “oh this would be nice, oh great let’s add this part, it does not look too complex” etc.
tl-dr Yes capabilities, but my focus is on getting the “rules” of data manipulation very clear to all of us and force us to work within those. So if we need more complexity we need to go back and confirm the new mutation type we want is secure and consistent, if that makes sense?