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)
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
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
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.
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!
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.
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.