SAFE Network Dev Update - June 25, 2020

Three backticks followed by ‘bash’ to start the block, and three backticks to end the block and you’re good. No backslashes needed if you are inside such a block. Single backticks to quote some text and you don’t get the full treatment.


That sounds Pythonesque… but works :slight_smile: when you type


cp target/release/safe `which safe`

Thank you.


I kind of wondered if the fact that Mutable is mainly a key value store if that’s why it made sense. So using Map will be more modular and light weight than running a whole Sequence to version something. I think I get the overall concept though not the exact details. Thanks @oetyng @bochaco


One of the reasons the alternative $(cmd) I mentioned in an earlier post exists: easier to use these to nest in comparison to the backticks. And apparently also easier to show the commands correctly here.


Well done team!! Having trouble getting into the Figma site to see screenshots. Any chance for them to be published elsewhere to see them? Love seeing the UI come to life being a non-tech person.


If you can try on desktop or laptop @Moose99 you should have better luck. Figma doesn’t play nice with mobile.


I couldn’t get the Figma to display either… :expressionless:


You can find a german version of this weeks dev update at:


Yeah, sorry guys, It is a bit of a hungry beast of a file. I may have to break it down in to smaller files soon to make things more manageable.


Yeah, this is a good point, but also a tricky problem. We won’t really know the best solution until we get an idea of how many decimal places end up being used for day to day spending such as this, the cost of storage etc. What is a significant sum to a user, and how is it best represented?

For example, if I’d really want to know about a spend of 0.01, but I’m not not so bothered about 0.00001, which is best to visually digest that in a pinch? Top or bottom?

Could quick a glance mean a costly misinterpretation?

We can provide for both solutions, and perhaps when we know more, we can tune it, and if needs be we could even have a setting to round to a helpful number to the users preference.


Thanks guys - I’ll just keep the browser open longer and see if it arrives. Super exciting stuff.


Or perhaps make all the zeros after the last meaningful value a lighter shade of grey, as some exchanges also do.


Yeah, or maybe make the meaningful numbers red in both values. I don’t know how to make them red here, so I use bold instead:

1.53331567 -0.01000000

But I think I’d still rather see these values on top / under each other:


From a user point of view having to pay for upload is one of the biggest differences compared to oldnet. It’s unavoidalbe friction and any unclarity adds to that friction. But it’s very difficult to estimate the meaning of this.

I am maybe comparing apples to oranges here, but from personal experience I have found it surprising how it is not possible to play poker in any meaningful way without any stake - and how even the smallest of stakes is enough to make the game exciting. The psychology around money is weird.


What is meaningful perhaps follows from the cost. If the cost is meaningful in a real world value, then it’s worth noting; and showing like for like rather than any other fraction perhaps best to avoid confusion.

So instead of this

Just what is significant for most occasions, with some option on drilling down to trivial of the full balance on a balance summary.

everything then less that the base cost is hidden as dust, unless user really curious about it.

The other aspect of course is what defines order of magnitude. I’d suggest the decimal point is not more than a few places above the cost as people will get confused with math they can’t voice.


I don’t think it makes sense to display cost per file. Like mobile data usage, I’m not interested in the cost of viewing a web page, downloading a PDF etc.

It’s too much work, it’s easier if we can set a budget per month (per week or per day if we prefer) and need to know how we’re doing relative to that.


And thus we begin to unfold the complexities of the design problem of just a small part of the app:

  • Finite but wildly variable screen estate, both horizontally and vertically
  • As yet unknown cost of data
  • (Varying) Colour conventions, especially around financial transactions
  • Unknown significance of decimal places
  • What is a significant spend for users, and when is it appropriate to even show costs up front?
  • Task friction vs. perception of control etc.

That’s why we are doing a bit of bet hedging here, aiming to make something out of components that are reasonably flexible to deploy in a range of circumstances, knowing that they will never be perfect, but can be refined adapted and updates as we learn more.


Keep it simple… and skinable.

If there is opportunity for the UI to fit the user, then alsorts of solution can arise.

If the UI is spawned on the back of a simple API, then surely it doesn’t matter… though at the start I wonder people will be curious the actual cost of actions… others will want a less verbose presentation.


Am sure there was a tread a while back on the challenges of displaying multiple zeros/decimal places - there were quite a few ideas I remember. I really don’t like having to count each time, and am sure there must be some useful shorthand design trick to help with this.


I tend to agree.

If you check out the feature tracker, we are considering how all this fits together, and have work slated for after MVE in this regard. To summarise though, we are aiming to have controls that let you:

  • Apply sending limits: restricting what can be spent without intervention on a per app basis.
  • Apply global spending limits: specifying spending across all apps for a given period before being notified, or before an intervention is required.
  • Apply single PUT cost thresholds: the ability to specify a cost threshold for a single PUT, or mutation, before being notified, or before an intervention is required.

These three combined, together with the permissions sets and rules we have too, should be pretty powerful, with the object being that most data to day use will be pretty seamless, and I only need to be interrupted for significant out of the ordinary spends, or when I go over certainly budgets.

And when these things can be balanced alongside income from vaults, hopefully these kind of flags will be the exception not the rule.


I think this is a good starting point. I’d be inclined to include a limit for any single app as well (not a limit for each app, but one which is triggered by any app in the chosen timer frame). I think this could be set relatively high just to catch rogue apps or apps we just installed without realising they would cost a lot to use.

I think this is useful because some apps will not just spend to PUT, but be able to spend in other ways.

But not necessarily for MVP. We have to start somewhere and I’m happy you have this well in hand Jim.

This is going to be so much fun to actually play with, so I don’t want anything to get in the way of that :smile: