SAFE Network Dev Update - March 12, 2020

[Shane]

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

[davidpbrown]

@Shane

Lurkers

Shout out to our #1 lurker Cantankerous

[Shane]

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

[Cryptoskeptic]

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

[oetyng]

Shout out to our #1 lurker Cantankerous

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

[JimCollinson]

@Shane

That sounds really good to me, I like the idea that the option for the app account to pay for the data storage is there

This is a cool idea.

@Shane

…it simplifies a lot of things which would otherwise result in lots of obnoxious SAFEcoin transfer interfaces in SNAPP.

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.

[Shane]

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

and:

for publishing of data

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

[JimCollinson]

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

[neo]

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

[JimCollinson]

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.

[neo]

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

[JimCollinson]

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

[neo]

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.

[joshuef]

@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.

[jeremyjpj0916]

@maidsafe

This is because all client requests that involved spending of safecoin were sent through PARSEC to reach consensus before processing the request further. This could take some time depending on the size of the request, the number of requests being processed, etc. We are aware of this and will be working to improve this in the upcoming weeks. That being said, in the interest of helping test other features (API, CLI commands, etc.) we will be removing the PARSEC step from the client request-processing flow and releasing a new version of the vault. We are testing this internally and once ready, we will release the next iteration of the Phase 2a testnet. With faster response times, we should be able to connect to vaults hosted on cloud machines and this means shared section Stay tuned!

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 ? Seems a really big wrench in things eh? But better to catch it now rather than later, iterative testing is good like that.

[JimCollinson]

@Shane

That sounds really good to me, I like the idea that the option for the app account to pay for the data storage is there

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.

[JimCollinson]

@Shane

And another question, since you’ve mentioned updates to the permissions flow here: Is it going to be possible in future to give public write access to an object you own?

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

or

2. 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.

[Nigel]

@JimCollinson I would pick the latter personally.

[Shane]

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

[Blindsite2k]

@maidsafe

Another new feature added since Baby Fleming is to support fetching a range of bytes from a file, which will enable streaming for SAFE apps. We’ve changed the fetch API to accept a second (optional) argument which is expected to be the start and end position of the bytes to be retrieved from the file targeted by the URL provided.

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?