SAFE Network Dev Update - March 12, 2020

would be for publishing of data, sharing of data, and sending payments to other individuals. Note that sending payments is a different mechanism to user paying the network for app data useage.

What’s the fundamental difference between:

user paying the network for app data


for publishing of data

Is it just the public / private status of the data?


There are several permissions that can be granted to an app (each which can have rules applied to it) allowing for an app to:

  • Create new data
  • View data
  • Edit existing data
  • Share data with other users (privately)
  • Publish data (making it public and perpetual)

and to

  • View a wallet balance
  • Fund data use (paying the network)
  • Send payments to other users

So, as a wee example, say I wanted to use Phantom to post an existing private image on a public blog I’d need to grant it permission to:

Publish data and Fund data use


Does making a private file a public file still require uploading it again as public


I’m not 100% up on the latest thinking on the mechanics of that, but clearly the ideal (and the aim) is that it would be seamless to the user. Perhaps someone else will chime in on how we’re working toward that.


This was/is the case where to make a private file public it has to be uploaded as public.

The reason being that private files have included in their chunks addresses the ID of the owner, thus cannot be a public file. This is to enable deleting private data

Of course you can have pseudo public by sharing the chunk addresses, but its still not public data


Yeah, as I say, we have been discussing it (to avoid the download/re-upload) but I’m not abreast of the latest thinking.


I had suggested a function within the section/node to send the private chunk stored on it to be stored with the public address, saving one of the paths through the network. Of course the user still pays for the new storing.


@neo there’s some further of the data type refinements @oetyng was working on which strive to address this. Short term, reuploading is necessary. Longer term, it’s looking like we’ll get that sorted.


Just to confirm here, we are removing what we considered reliable consensus checks between clients because confirmed too slow? Umm am I over-reacting here or missing a point that PARSEC was not needed here :laughing: ? Seems a really big wrench in things eh? But better to catch it now rather than later, iterative testing is good like that.


Been thinking some more about this BTW, and it may well be more complex from a app developer/business UX than meets the eye. A few things we’d have to consider:

  • Ways to limit the scope of the data stored
  • Limits to unique users/SafeIDs?
  • Controls to limit the size of individual data ‘purchases’
  • Controls/threshold to manage the overall budget spend both by unique user and globally
  • Feedback to the user when the above thresholds have been breached and the budget exceeded
  • And so on…

I’m sure we could find ways to cater for much of the above, but it would need to be well scoped out. And I’d hazard a guess not be on the cards for MVE.


I’ve also been thinking this through too from a UX POV. Two immediate routes to explore, either:

  1. Extend the publishing flow to allow for advanced options to accommodate this


  1. Fold this into the ‘Sharing’ flow, where there is an option to set the user to Public/Anyone.

I’d probably favour the latter option, as it would probably allow more nuanced control and use existing candidate patterns.

I’ll perhaps have a little explore of that idea when I’m working though the Sharing flow in more detail.


@JimCollinson I would pick the latter personally.


@JimCollinson I agree with @Nigel, the latter option definitely sounds like better / simpler UX.


So how does this translate into getting a functioning version of SAFETube working? Or maybe live steaming video chat or audio chat? Like what are the practical implications and how does it work?


Getting some streamable data uploaded to our local baby Flemings will be the first challenge. But once thats done and the actual range fetching is tested, my instant take on it is its getting the interface built and the subscription payment model defined. Something that I would not imagine needs much direct input from the core devs.
So get tore in…


I tested this version of SAFE Browser and it connects successfully to a non local vault base on latest Fleming branch. The file to update is:
with content like "ip-address:port".

This works but it allows only one contact node. In the past we could also create another file that allowed several contact nodes:
But I don’t succeed in using this method anymore. I tried various contents like:

  • ["ip-address:port"]

  • { "hard_coded_contacts": ["ip-address:port"] }

Can anyone @maidsafe indicates the file and the syntax for defining a set of hard coded contacts. The aim would be to set up a non local network.


From memory this was the format of the old hard-coded bootstrap files we used. I have cleaned out a load of old stuff from ~/projects/maidsafe so I can’t check.

Let us know how you get on when you get an proper answer, please :slight_smile:

tagging @bochaco @mav @StephenC @dirvine


json format, from here
So what you have is correct, there was a bug that @nbaksalyar recently sorted @tfa and that is in master


Coming back to this.

Can you please either inject the following into the conversation, or get them to look at this post.

In the past there have been a number of suggestions for how to handle private and/or deleting data. Each time there were major issues and out of that came the concept of making private data contain the owner ID within its addressing hash.

The big advantage is that it solved most issues in a KISS way.

So if things change can they discuss it with the community before they get too far down the track so that any issues can be discussed prior to development. Sometimes keeping it simple makes it more powerful a feature.


Thank you for the heavy work team MaidSafe! I add the translation into Bulgarian in the first post :dragon: