SAFE Network Dev Update - March 12, 2020

I bet there are a tonne of people just silently and patiently waiting on the Maidsafe team. Lurkers.


Shout out to our #1 lurker Cantankerous :partying_face:




We’ve finally reached the meme stage of the SAFE network


Yes, we have the technical people that are active on the forum, technical people who lurk in the background, speculators of the same 2 types, short and long term investors of the same 2 types and then there are people like me who are sold on the idea with small to moderate holdings and no idea what the tech speak means. What a diverse population we have


Lol, I didn’t realise. That’s some epic stats @Cantankerous :joy: Awesome.


This is a cool idea.

Although, unless you specifically want them, there won’t need to be lots of obnoxious Safecoin consent screens appearing every time you use an app. We’re designing with a system of default permissions, and ultimately data spending thresholds, to allow things like funding data use to be almost frictionless.

Where there, rightly, should be roadblocks—what I’m calling Just in Time Consent—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.


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?