SAFE Network Dev Update - June 6, 2019

Yes, I think we are talking about the same type of scenarios, let’s say you have messages/email app which at first it requests access only to read/write messages from some container supposed to hold the messages (a container which is a standard for many apps of this kind). First time it requests perms for that container, you get the popup and you authorise it. From there on the app can work fine reading and sending messages, but as you said only with the default theme. Once you go to the app’s settings page and go to change the theme, the app can say “well, if you wanna enable this feature we need more permissions” (I guess this is where you use the API linked by @happybeing above), if you say “yes sure” the app can send that other type of containers auth request asking for one single more permission, the permission for the themes container, you of course get the second popup in this case. After that, everytime you launch that app it will get all permissions, and if the lock-pad is unlocked you won’t get a popup. Does it make sense? is this what you are looking for?


Yes, that’s the sort of thing I’m talking about.

I guess the place where I would need that bit of the API is actually the step before you suggest above, in the sense that we want to find out what permissions the user who hasn’t yet authorised the themes container has, (in order to serve them to the person who does have the permissions) without troubling them with the pop-up until they click for the thing that actually needs the extra permissions.

I think @happybeing’s link is what I’m after. Now I just need to write a function that picks out a specific permission from the returned list!


What is quic-p2p? Does it have any relation to Google’s QUIC protocol? Why moving away from crust? Didn’t you just move TO crust?

Yes, it’s QUIC protocol. You can see more details about it in this post or in the previous weekly updates from the past month or so. They’re using a rust implementation of QUIC called quinn, and built upon that with quic-p2p.


Sad to see anyone leave but redundancies just seem to be harder. Hope you both @kayley & @DGeddes keep your spirits up (as much as possible) through this tough time and we don’t loose touch. Thank you for all both of you did for the project and you find great jobs and adventures from here.


I should add to this discussion that the UX that we’ll be exploring and testing in the first instance is the Data Sharing Controls model. This is where your data space on the network is akin to your computer hard drive: you can use apps freely to read/write without explicit upfront authorisation, but need to authorise any action that would publish or share data.

You’d still have the option to turn on more traditional Access Controls for each, or every app—and we can provide for a locker/enclave within your account where this is the default.

Going with this approach aims to reduce the permissions fatigue that would not only make for an arduous UX, but also could end up being less secure than it at first appears, and not take advantage of the great data control model that SAFE enables.

Again, this is the approach we’ll be taking initially on UX design, until testing, feedback or other constraints push us in another direction. It’s better to do this, than invest in working up a much more complex UX, only to tear it down later, or not have the space/time to realise the more human centred vision.

There is a great thread on it here BTW, with some really useful ideas, which would be a good place to chip in if you’re interested.


Nice. I’m a very happy being to see this being tried. Let me just say… woooOOOOO HOOOOOO!!!

If we can make this approach work it could improve privacy and usability a lot.

That’s my hope anyway, because I think it can discourage dark patterns in apps - by making such patterns irritating to users, and discouraging use of such apps.

In this post I compare access control and publish/sharing control, and explain what I think are the benefits of the latter.


Absolutely, I think it’ll make a much more elegant, humane experience too. It’s a lot faster to get going with, and should work in nicely with the layered approach we’re taking to the design too.

I think one of the biggest hurdles will be the already very ingrained mental modals of how web apps work, and unwinding that for folks.

Is gonna be fun working it all out!


I should say a thank you for that post BTW. It really helped clarify my thinking on this, and distil down a bunch of ideas that i’d been mulling over but couldn’t quite articulate.


That you had been thinking along these lines already is a good sign.

I love the stage of the creative process, when I feel I’m into something and am struggling to find it. It feels so close! Sounds a bit like that. :slight_smile:

How are you thinking about taking this forward, and do you think further backend changes may be needed, or can we start with the new data types and modify the backend later?


There may be backend/SCL changes, or maybe not, it’s too early to tell and the devs focus is elsewhere at the moment but will circle back to this. It’s useful in this case to work through the UX to help inform those changes though, and it’s relatively low cost as it’s the more simple experience to design around.

It’s a ‘best-guess’ at the UX that’ll then be informed by testing, and shaped if there are tech constraints. But starting from the human need is always the best approach.


Thanks for sharing weekly updates :slight_smile:


Thanks Jim

I think I remember that thread actually, and I may even have chipped in at the time!

I really like the idea of the Data Sharing Controls model, and seeing the SAFE account like one’s hard drive. For what they’re worth my first thoughts on this hard drive model are that:

A) It will be tricky (but far from impossible) to switch people’s mindsets,
and B) Once people see things that way, it will suddenly seem totally normal, and will be dangerously close to killer app territory!


Many thanks to @dgeddes and @kayley for all your hard work @ Maidsafe, good luck and see you in the community.

Great update Maidsafe devs and happy to see that you still don’t shy away from everything new that can speed up the development process, I wouldn’t be amaze if one day you used machine learning to code/compete against you super ants.



That reads like an important component for green lighting Maidsafe’s top secret enterprise business …if i’m interpreting it correctly.


Probably a dumb question. If priority focus is on Fleming, why is the RFC on the BLS Section Key (a Fleming deliverable) not yet out and the RFC’s for Maxwell deliverables out.


Do you mean this RFC RFC 59: Boneh-Lynn-Shacham scheme in Routing - #6 by Lindsey


Bonus: Bruce Schneier is also speaking - would be great to grab his attention if you can.


If that is it, then the little box on the Fleming tasks needs to be ticked.


This is new to me, so I thought I’d point it out.

I noticed on the update Twitter $MAID was used instead of #MAID. It is a thing, maybe I’m slow to catch one.

$ looks like it’s used for finance topics.

$MAID also prevents some surprising photos from popping up if you are searching for #maid