SAFE Network Dev Update - June 25, 2020

Yeah, this is the plan. This, together with data labels that restrict usage to just an apps own data, will cover a multitude of rougeness.

Yeah, we have split permission for apps when it comes to: Viewing financial information such as wallet balance, funding data usage, and sending payments.


Although a “trip meter” style of thing in the wallet (APP level) would be good. And to have multiple trip meters as desired where the user can add a new “trip meter” and if they was 2^32 of them then let it since its their data and in an APP. Mighty hard for them to keep track.

The trip meter simply has the starting coin balance and coin transferred into the account less the current balance. Thus only need to store two values plus a date (PC clock)

  • starting Balance
  • accumulation of added coin

This means I could set one up just before uploading a big file (say 1TB) and come back when it finished and see the cost. Of course I may have transferred more coin to the coin balance during the upload

And yes it would include other activity. But I may say do it overnight and transfer from an aux account


My preference, including posts above is for Jim’s top example to be adopted. Why?

  1. It’s consistent. Eight decimal places for each; balance and cost.
  2. Allows for future needs of dividing a coin into small units but is not completely unwieldy.
  3. Provides a fixed space allotment that should be sufficient for current and future apps.

Yeah, it’s a bit ugly but sometimes function should prevail over fashion.


Would cost vary over upload of large file?.. and if so, what occurs if no payment is forthcoming… or is the max it could cost held in escrow.
What happens on disconnect of upload part way through … can there be option on resume?


Agreed. I think giving the user easy optionality would be a good thing here (e.g. toggle switch in preferences). That being said, UXR would still be needed to figure out what the default setting should be and how to best communicate that the number of visible decimal spaces is a customizable option.


Its the client that uploads the chunks it calculates. So resuming is simple, either the APP starts from where it left off. OR it does a check prior to attempting to upload chunks. Maybe do binary search for what chunks are already uploaded.

Costs would likely vary on upload, but since the trip meter is only looking for total cost from when the meter started then it is not concerned with that.

If run out of funds then its up to the client. See my first point


when we will have another toy?


Just have a rounded set amount for data storage amount like other cloud products.

Example: 1 safecoin for 10 GB. Display a warning when the 10GB is almost full, so more can be purchased. When safecoin price changes, that 1 safecoin will either buy you more or less storage space.

Keep it simple.

Most people won’t get decimal points.

For advanced users there can be a details button, or link, attached to the inner workings of cost per each upload, displayed in decimal, for those interested. Just an idea.



I had a daft idea earlier to make it complex - that the only fixed constant should be the upload cost and everything about the value relative to that. What effect that would have I can’t quite get my head round. :slight_smile:


I’ve been thinking about this. It’s a nice idea! But is it workable? We’re talking here about pre-purchasing data at a fixed cost… so isn’t that either:

  • A fundamental re-working of the network?
  • Some sort of farming futures market?
  • An intermediary financial service business?

And, aside from the fixed pricing, is it so different from say loading up a wallet with a safecoin, and then only being notified when your data usage has depleted that wallet below a certain level?


But once the network is matured (large enough) then the changes in price during a file upload will be minimal. Even if it takes a day

I think he’s addressing a different problem though, not the cost estimate, but the PUT cost variability, and dealing with small fractions of a safecoin for individual actions, and how to make that feel less cumbersome.


Exactly. And I’m no expert, I’m not sure if the math would work for this. I’m just looking at it from an average user perspective.

If the network could offer a 1 to 1 transaction in safecoin, like $1 worth of data is 1 safecoin of data, when the user first encounters the network’s offer, they will not be Frightened by Incomprehensible decimal point equivalents, which we crypto heads must deal with when deciphering prices and current values translated into dollars and BTC rates.

I’m talking about keeping it simple, to ease the learning curve for regular people.

The biggest thing keeping people away from crypto is the complexity.

So far the safenetwork is presenting itself through the UI as the most user friendly network to date. And this is great. But I’m not sure if the safecoin can be calculated differently, or even if it should be. Probably not.

But it still would be nice if we could get away with using rounded numbers; and then leaving the decimal, or true value stats for advanced users, under a menu option, like getting under the hood to see how the engine works. Just some thoughts, cheers!


Beyond that though, surely rounding is quite reasonable and uncontroversial. Why should we need to make micro fractional calculations and not something that is rounded?

Into what real world shop would you go and pay beyond the second decimal point as pennies?.. no-one contests the round up/down or cares to query which it was.

That crypto can do micro payments, does not require that is does in all cases. Also, dust is pina for cleaning up old accounts.


What if there were two segments to a wallet, rounds and fractions. Nothing on the backend would change just the wallet UI and how people interact with it, not sure how it would impact farming or how that would be represented though.

You could buy round Safecoins and once it is unrounded by an operation such as upload, the rest is only visible in the fraction portion of the wallet, but is dedicated to future small cost/fractional operations. If you got say a farming payout that increases your fraction amount to a round number then that would be added to the round (default) portion of the wallet. Overall this would be completely unfamiliar territory, might be hard to keep track of funds or costs, maybe clunky? But perhaps more usable for the average bear. Just a thought.


Maybe we could dispense with fractional and decimal accounting altogether and just rely on plain English nomenclature using the metric prefixes:
1 microsafe = .000001 safecoin
1000 microsafes = .001 safecoin (1 millisafe)
10000 microsafes = .01 safecoin (1 centisafe)
100000 microsafes = .1 safecoin (1 decisafe)
1000000 mocrosafes = 1 safecoin
1 decasafe = ten safecoins
1 hectosafe = 100 safecoins
1 kilosafe = 1000 safecoins
1 megasafe = 1000000 safecoins

Too complicated? Most of the time, at least in the beginning, users would be working with a specific number of microsafes and that could be the default unit for most apps. The actual conversion would take place “under the hood” and users would be spared the agony of working with decimal places. The goal would be to simplify currency valuation issues for users, especially novice users. Am not sure if this suggestion accomplishes that or not. Might be worth consideration though.


Personally I think all that nonsense was too complicated for bitcoin… swapping from the highest unit (bitcoin) to the lowest unit (satoshis) was enough… all the variation of decimal places was overkill and confusing for the most part.


Yes, I like this idea. I think people will get used to crypto math overtime, but to get them started they could be using rounded numbers in the beginning for simplicity sake. Later they can delve deeper into decimal fractions.


Also a great suggestion. It is worth investigating indeed.

1 Like

Jim - it’s great that you are addressing these challenges as a UI designer, but given that these challenges apply to many areas of crypto, for wave 1, please do not feel the pressure for perfection - it is the enemy of good. Nevertheless, really interesting discussions and a good intellectual and design challenge.