MaidSafe Dev Update - November 8, 2016

Last week, we released the third dev tutorial (WebRTC video chat app).

The next tutorial is going to conclude the tutorial series for now. The existing tutorials are still going to be supported, but there will be a period of no specific activity in terms of new tutorials. We are currently discussing the future of SAFE Launcher and we are about to present a couple of RFCs related to that.

Our idea is to change the SAFE Launcher to a SAFE Authenticator, which would only be used for authentication/authorization process: Once an app has a token, it will be able to directly interact with the SAFE Network (using a language binding we provide). We want to make this change in order to be able to support mobile platforms (Android/iOS).

Also, we would like to bundle SAFE Authenticator directly within SAFE Browser. That way users wouldn’t have to download two separate apps. They could simply download SAFE Browser and use it to create an account or log in to an existing account.

See this Dev Forum topic on for more info.

SAFE Launcher

We have been working on the last example that was planned for the tutorial series. We are also trying to fix some of the issues that were raised in the safe_launcher repo.


Async safe_core is done. All examples and test cases pass. We will continue to keep it in dev (along with self_encryption which is also in dev) until all frontend code interfaces with it, works and finally the frontend guys give us the green flag, at which point we will move it to master and do a crate publish.

We are now looking into sketching out the paradigm of how things are going to work with mobile and have some sort of design that will work well both on desktop and mobile. This of course changes the FFI layer and the fundamental concept of Launcher as a single point of contact (doesn’t work on mobile) but we think we can have an agreeable solution to it (we are working on putting up an RFC). Currently we are analysing from the point of view of safe_core, routing and safe_vault and noting down all that we will require in terms of changes to support a SAFE Authenticator based paradigm.

Routing & Vault

We’re still in the process of re-enabling the mock Crust (i.e. without a real network) tests, one after another, and fixing all issues that we discover that way. Last week, we’ve fixed several issues with splitting groups (when a group is large enough, it splits into two new groups). We feel that some of those fixes are workarounds that we won’t need with a slightly better organisation of the joining process – keep a node in a separate container until it has made all its connections and is ready to route messages – so we will address that next.

At the same time, however, with group splits being functional, we will enable the tests for merging groups, and for churn handling in general.

Once that is done and all issues are resolved, we will move to in-house network tests with actual vault binaries, and work towards stabilising these: After a change to such a fundamental concept, we expect to find some regressions all along the way. However, this stabilisation process remains our top priority: We want to produce vault binaries that users can run from home as soon as possible.

In parallel to these efforts, we are working on the new message routing/accumulation algorithm: We ripped out the old one and are replacing it with collecting signatures in the first hop. After that is done, there are two more steps to secure message routing: Each group will have to maintain signed member lists of all neighbouring groups, and then it will need to append the appropriate list to each message it is relaying. That way, a message sent from group A via B and C can be validated by the recipient D: D knows the members of C, who have signed and attached a list of members of B, who have signed and attached a list of members of A who have signed the message itself.

Finally, in our discussions of the security simulation results, we concluded that:

  • We want to extend the simulation to include more attack scenarios and make sure it makes worst-case assumptions.
  • We will look into ways to allow larger groups without impacting performance.

In before whiteoutmashups :stuck_out_tongue:


We are so proud of you and your amazing accomplishment against all the odds

Devs done well and alll BTW ;->


But seriously folks, solid evidence of steady progress and excellent communication.
Quite apart from the fantastic technical advances, this project is an object lesson in communication and community engagement for all Open Source projects.

Thank you again to all involved.


The paradigm of how things are going, you might say :wink:

I’m hoping that the [Enable Comment] bug is getting a look at too, as that seems to get stuck a couple of days into a test, across all websites using that - it seems then unavailable. Less of a browser or caching issue and more a network oddity, I wonder.

Worst case is the network falls over and I don’t know if any thought was given to the idea of a Local failsafe as a route to confidence in an unstable network… I put it out there as a route to evidencing robust response to worst case, allowing network to bounce back and just reupload data, though I’m not sure that’s a complete solution; as there are elements within the network that can’t be so easily backed up - like coinage and tokens… unless those are audited into a ledger perhaps. Still, the best defence is something that sees a simple resurrection… and perhaps it would allow a solution for tests at least that saves users time reuploading content.


great news :+1:

More great news :+1::yum::+1:

A lot of improvements. Keep up the great work. Can’t wait to test the Vaults again.


Yes!!! This is a great move for sure!


Me too


Lol I got busy.

Dang. 21st… Slightly off my mark :stuck_out_tongue:


Great update Maidsafe devs,

If possible: demo app + SAFE launcher + SAFE browser :stuck_out_tongue:


Or make the demo app into a website / web app perhaps? Instantly will work on mobile? Hmm…


MaidSafe’s CSP headers were removed when the proxy was removed, correct? So js listener functions like this aren’t necessary anymore, right? Since you can put it in the html with < button onClick=“xfunction…”>

1 Like

yes, the proxy has been removed from the latest versions of SAFE Launcher (e.g. v0.9.3)

yes, I don’t think they would be necessary anymore :slight_smile:


no it’s not a network issue. if you use SAFE Browser v0.3.5, you can see that safe://diy.yvette works fine :smiley:

there were some changes to the authorization code in the latest versions of SAFE Browser and we haven’t been able to update the previous examples yet. we are working on updating them now :slight_smile:

In v0.3.6-2, the authorization code looks like this. And even more recently, the Beaker specific code was moved to beaker-plugin-safe. so the authorization code for safe-js now looks like this and SAFE Browser takes care of overwriting the authorise function. so basically there were some minor changes which means we have to release updated versions of the comments plugins.


Well done! Thank You for reporting the progress!


I’m looking at the active RFC-page at the moment and I’m a bit confused:

Async safe_core is “proposed” but it’s actually done?? Even while it wasn’t an active RFC?

Which RFCs will be part of this? David linked to his personal repository called: resource_proof some time ago. I guess that one is needed to filter out the slow nodes?? As far as I understand these are the main RFCs which we need for a full data implementation of SAFE:

  • Disjoint Groups
  • Node Aging
  • Datachain
  • Resource Proof

I leave out the Farming and Safecoin for the moment, just to focus on data. So which RFCs will be part of the upcoming Vaults??


Good points. I think the RFC status’ need to be cleaned up. I think there are routing simulations using node age that diggory has done so that is in there as far as I know. The resource proof is the first thing to happen upon connection of the network but is that part of routing? Core? That I don’t know but do know it’s written up in davids repos, although it states it’s for a general measurement so not super precise but must be good enough. When it comes to data chains, it is what will keep data persistent but routing will most likely be tested from home first to make sure that consensus, resources are all running smoothly.


Well, the truth is that the RFC system gives the impression of being underutilized. Not only seems outdated, but, sometimes, developments are almost finished without any prior RFCs. It may be the price to pay for an accelerated development.
Personally, even if I scrutinize the github to try to understand where we are, must recognize that I am quite lost.

After Disjoint Groups with the new message routing, who seem harder than expected, and Async Safe Core (done), the next moves, as I understand, can be:

in Routing-Vault:
Subgroups (for the moment only a proposed RFC)
MapData data type (Not RFC yet, now is only a proof of concept),
Node Ageing (agreed RFC)
Resource Proof (not RFC, maybe can be added to node ageing)
DataChain (proposed RFC)

.-In Launcher-Core we need the RFCs that explain the substitution of the Launcher by the new Authenticator. Of course the Core will need take control of most of the responsibilities of the former Launcher but without those RFCs we can only speculate.

Maybe some kind soul can enlighten us…


Yes, it should have been moved to active earlier. I just opened a PR to fix that :smiley:

It’s not entirely done yet, because we still need to integrate it with the frontend code and test it on a testnet :slight_smile:

Disjoint Groups and Node Ageing.

We are also doing a lot of RFC planning and discussions and proof of concepts, which may or may not turn into RFCs.


The RFCs for the new Authenticator are almost ready, we just need to agree on a few details. We are aiming to present them early next week :slight_smile: