MaidSafe Dev Update - October 25, 2016

Last week, we updated the second dev tutorial. We now have two comments plugin: one for permanent comments (using immutable data) and the other for editable comments (using versioned structured data).

SAFE Launcher

The launcher implementation of API 0.6 is almost close to completion. A chore work of validating the APIs is being carried out. The gaps in the implementation are planned to be identified and addressed this week. The limitations listed in last week’s release (UI logs and dashboard glitches) should also be addressed in this week.

The test suites have been expanded to cover the low-level APIs. This is a good place for devs to look and learn more in addition to the example apps.

As for the discussion about app permissions and app management, we are now starting to agree on one approach. We are currently fleshing it out and we aim to start a discussion on the dev forum later this week. The ideas presented will still be open to debate by the community and we’d love to hear your thoughts and feedback once we post that topic :slight_smile:


We are currently driving the async safe_core task to completion. The whole crate has 4 top level modules - core, nfs, dns and ffi. We are done with the first 3 and are currently on the 4th. It’s a huge task but looking at the current progress we should be close to completion, if not already done by the end of this week.

Changes and progress can be tracked in the dev branch of the safe_core repository. All changes required by Launcher/Frontend are being made into master while also being ported to dev in parallel.

Routing & Vault

The main missing pieces of the disjoint groups implementation in routing are finally in place, and Bart and Fraser are in the progress of updating our tests – and fixing all the bugs that the tests uncover. After such a large change this is to be expected and we want to get the core part of the new feature right prior to implementing the new secure message routing.

Simultaneously, Qi and Andreas are already starting to migrate safe_vault to the disjoint groups-based routing in a new “dev” branch. The disjoint groups approach will require some changes to how client accounts are managed and how data is relocated.

Diggory is making huge progress on the security simulation that will produce estimates and optimise some parameters like group and quorum size. This will help us make informed decisions in the implementation of the Node Ageing RFC.

Dev outreach

After starting last week with the first two official Developer Meetup Groups in Berlin and Amsterdam, two more continents were added to the list: first Melbourne, Australia decided to join the list, then the MaidSafe Group in Cordoba, Argentina decided to rebrand itself, too. Additionally, Ben (@lightyear) was invited for a remote-presentation at the Manchester Bitcoin Meetup on November 7th. And after the Bitcoin Wednesday meetup on December 7th, we will have our own kick-off meetup on Friday 9th in Amsterdam, too. It looks like there might be quite a few team members around in Amsterdam for that one. So, if you are around any of them, make sure to come by!

Secondly, we’ve added some more communication and outreach related categories to the developer forum: a section for announcements, including developer events, and another more general community category. We will be using the latter to communicate outreach materials like slide decks but also guidances like how to start a meetup group or become a SAFE developer ambassador yourself. Stay tuned, these are still in the works :wink:

If you are interested in starting an official Developer Group (not all organizers have to be developers themselves!), please send @lightyear a private message!

We also want to take a moment to highlight the new team members who joined MaidSafe recently :smiley:

From the routing/vault team, that’s Bart and Diggory. Bart is working with Fraser on the Disjoint Groups implementation and wrapped his head around the RFC, but also Routing’s message flows, tunnel nodes, accumulation and other features amazingly fast. And Diggory is designing and building the complex simulation tool and already has lots of valuable ideas regarding security and the Node Ageing RFC.

As for the safe core team, Nikita has hit the ground running. He has picked up stuff really fast and is submitting big and important PRs along with Adam.

And in the frontend team, Ben is very active and contributes a lot to the discussions. He has been working on the examples (for the dev tutorials) and churning them out at a great pace. At present, he is more tied up with the dev outreach submissions. He is of great help to improve the APIs and always on toes to look for improvements :slight_smile:


Ah great! I wanted to ask about simulating stuff, but forgot it. looking forward to it!

Btw, have you thought about making some sort of visualiser for the network? It’s probably difficult because of all the anonymity, but it would be so cool to “see” something!


This is really nice to see. SAFE is going global to an event near you ;-). Great update @frabrunelle. As always a :+1: to the whole team.


I have been watching the new recruits like a total creep on github and it’s cool to have seen them settle in so quickly, some bright and competent minds for sure. So congrats to maidsafe and the new devs for a prosperous future together and the community wish you well :slight_smile: So node age is making its way into the simulations that Diggory has built, yes? This is great progress and it looks like with this speed vaults and clients will be together once again very soon! Great to hear async core is almost done! @ustulation I’ve seen a lot of commits from you on this so great work to you and all others as well! Thanks for the update @frabrunelle


I’m looking forward to the discussion on app permissions. I think it is important to enable different personas that take into account various threat models and delegation of trust. Some users won’t want to go through the trouble of managing their security. For a social network user, it might be fine to use a permission system like Android’s that just presents the user with some categories of permissions that an App requires, whereas for a political activist or whistle blower, it might be critical they are notified each time sensitive info such as personally identifying information could be compromised by a given action.


I am looking forward to ability to run apps via bash script on a headless server. Hoping API changes will allow this

This will make my app more vulnerable but I am comfortable with that trade-off and it will allow me to spin up remote hidden services servers,. First project, some sort of chatbot that safe users could SAFEmail and it would respond back.


Thanks for another great update Maidsafe team,

Wow luckily not, but I need to find some devs around my city first, but would love to do something like this and get of my lazy &**^%%%$. :stuck_out_tongue:


Hi @Tom_Carlson, why aren’t you able to develop such an app now?
Aren’t you able to develop something which uses the safe_core library directly already?
What I mean is that you can create your own headless launcher, is that what you meant?


Another great update! Thanks so much for all of the hard work! Welcome to the new members!


I almost worry that this is dangerous slippery-slope thinking, unless I misunderstand. Shouldn’t everyone have the best privacy possible? But i understand managing auths can become tedious… we’ll see in the discussion!

1 Like

There will be various launchers in any case, right? It’s something that will “naturally” happen. If Im not mistaken, permissions will be handled in different ways depending on the use case. Nothing that can be prevented, imo.


Yeah, that’s what I was trying to ask by making my other thread. I personally think the routing vaults SafeCoin etc are all the most important parts, and the vast majority of resources should be going there.

These launchers/ front-end stuff will all be made very quickly by the rest of the planet once they have a secure decentralized internet of freedom to finally operate on :slight_smile:

3 Likes will be changed today. The event info is located at


Is API v0.5… and the v0.6 diff simply looking to add the low level API options detailed in RFC#41?.. or might existing API be tweaked too?

I can’t see versioning detail on that to be sure.

1 Like

Sure, but the best privacy possible is a vague concept that is not necessarily the same for everyone. Not everyone is capable or inclined to alter their behaviors to facilitate the best privacy. Also, I’m not sure there is such a thing as “absolute privacy.” There are tradeoffs between privacy and convenience, and I think a permission system should make it clear what those tradeoffs are. So maybe rephrase that as, “Shouldn’t everyone have the best privacy possible for their use case?”

1 Like

Yes but also trying to maximize the privacy that people have, regardless of what they’re doing.

Striving to keep all things as private as possible is best development.

This is going into unproductive philosophy, so I’ll stop, but just wanted to say something after I heard someone say “social networking privacy isn’t as important”

1 Like

yes, currently only API v0.5 is documented. I just modified to make this clearer :slight_smile:

yes, v0.6 includes the low-level APIs. and also the removal of the web proxy from SAFE Launcher.

the existing APIs are the same as far as I know (other than a few bug fixes).


The problem is that the dev branch of safe_core and safe_vault crates are not compatible because they don’t use the same routing version:

  • dev branch of safe_core uses routing = “~0.27.1”

  • dev branch of safe_vault uses routing = { git = “”, branch = “master” } which is “0.25.1”

It has been months I have been looking for a combination of compatible crates to do development in rust in the development branch (with disjoint groups). The way this dev update is formulated I was hoping this time was right but it is still not good.

Please, consider providing such compatible crates on github for people outside Maidsafe.