MaidSafe Dev Update - April 20, 2017

This week we are continuing to make progress towards our goal of releasing a testnet with Mutable Data support, as explained in last week’s update:

One thing we need to address for the next testnet is clients spamming the network with various requests. Some potential solutions are being discussed in this Dev Forum topic. We haven’t picked specific solutions yet, but it’s likely that spam prevention will initially be a bit more aggressive than we ultimately envisage in the long term. This is because of the small number of Vaults in these testnets and we want to make sure that the network can’t get abused when it’s at its early stages like this.

There are a lot of things that are in progress and dev updates are likely to be short while heading to the next testnet with Mutable Data.

@Shona (the front-end designer who was away for a while) started to work with the front-end team this week, reviewing the UI & UX for SAFE Authenticator and the client apps. So we will once again be working on UI design and thinking about how the user experience as a whole is coming together, which is something we haven’t been focussed on recently.

SAFE Authenticator & API

The API issue with Electron has been resolved and the fix (fix unsafe pointers returned by FFI functions) has been merged in safe_client_libs. With that out of the way, we also had a few minor bugs/enhancements passed to the safe_core team. @nbaksalyar has addressed most of them and we are updating the FFI bindings to support the changes. We hope to do some regression testing using the mock network early next week. Stabilising the authenticator and the apps against the mock network is the priority for the upcoming week.

@Kumar is continuing with JNR vs JNI for Android. JNI involves more work and maintenance, while JNR would ease the work immensely. Hopefully, we will have some results to conclude by next week.

SAFE Client Libs & Crust

Routing and Crust had separate identities with the Routing layer uniquely identifying itself with something called a public ID and Crust by peer ID. This lead to some RPCs giving only part of the information causing a lot of additional bookkeeping. To reduce this maintenance hassle, Crust is now completely templatised to take a unique identifier given some properties it defines via an exposed trait. This PR is ready for review and merge. We might plan and expand this further to make it securely (encrypt and sign) serialise the Crust payload, again by renaming and expanding the scope of the trait, in the future. Also, there are some thoughts on templatising based on the Routing messages too, so that we don’t serialise and deserialise at every crate boundary. This should give some performance benefit and will be taken up in a later phase.

safe_client_libs had some fixes implemented. The Authenticator used to return an Auth-Error if an already authenticated App tried to re-authenticate. However, there are valid cases where this could happen. For example, if an app was authenticated in machine-A and now it was installed in machine-B and tried to get the required Auth-granted packet from the Authenticator, the Authenticator would simply return an Auth-error. So this is now relaxed to always return the expected payload via Auth-Response.

Invitation-based account creation is also being ported to the dev branch in this PR.

Routing & Vault

With PR 1430, we finally have deterministic mock Crust tests: Any failures in the simulated network will now be reproducible on any machine, so that they can be studied in detail and fixes can more easily be verified.

The final part of resource proof has been merged, moving the CPU challenge part to a separate worker thread.

We are looking to derive a node’s name from its public signing key and make Crust use the same key pair as Routing as a peer identifier, to simplify the current implementation as well as the future work on data chains. The first part of this change is almost ready. Currently Routing identifies nodes with a mutable public ID, and Crust uses its own “peer ID” type for the same purpose. Having only a single, immutable identifier will help us make the message flow and several data structures less complex and easier to understand.

And finally we are working on some long-postponed security checks to make sure we never add an entry to the routing table without verifying that the node in question has passed the resource proof and there is a consensus in its section that it joined the network by completing the proper relocation process.



Everyone fell asleep :slight_smile:


You said Tada bbbbbbbbbbbbbbbbb yes bbbbbb bbbbbb?

1 Like

Nice! Keep up the hard work and steady progress.


Great work guys! I hope we get some more information about android next week :grinning:


Things are moving in a really positive direction in my opinion. Good work and glad to see so much happening :slight_smile:


Very clear update as always, keep up the good work :+1:.


Yes, as always, thanks so much for all of the hard work! :slight_smile:


Thanks Maidsafe devs, from my clueless consumer perspective I can only admire all of the hard work.

Hang in there super ants, your doing something exceptional on this planet.


man. Could someone help with a mock-routing tutorial for devs, so we can work on things in the meantime? Vietnam is planning a large meetup in a week or two and we really need something to work with. Was kind of expecting a network this week, but it’s fine if we can figure out this mock-routing feature


Don’t have time myself, but you could try the instructions (h/t to @JPL for his “10 Key Facts…” topic):

And if it doesn’t work submit an issue.


Thank You for the update! Looking forward to next iteration of network :slight_smile:

1 Like

Have you tried following those instructions @whiteoutmashups ? I plan to give it a try this weekend. If successful I’ll attempt a ‘how to’ guide.


yes, I guess I was thinking like more of an open discussion on using it, if anyone has

I built it before but didn’t really understand how it works. Like it’s a fake network?

I’ll look back into it when I’m at my PC

I got it working - fairly straightforward.
Certainly I can now fire up the browser and get on with trying to understand safe-nodejs.
Still havent managed to actually upload a file though…


Hmm … not going so well for me. I seem to be missing a file package.json

You need to clone the SAFE Launcher repo and follow the instructions in the README here :slight_smile:


Yes, that’s what I’m doing (although I downloaded the zip rather than cloning). Then I ran the build script
cargo build --release --features use-mock-routing which seemed to go fine and copied to src/ffi
After that I ran npm install and got a few warnings then npm run rebuild-native which failed.

Any ideas what I’m doing wrong?
EDIT: ah … do I need to run those npm commands from within the launcher repo folder ?
Yes - I’m being an idiot… bear with me!


Linux is done now and I’ll post the binary tomorrow. Windows isn’t behaving though, it’s failing to compile rust_sodium-sys in safe_core. Anyone have any ideas? I’m using Rust 1.16.0 btw.


OK I give up on Windows. Life’s too short, it’s a nice day and the Launcher is not long for this world anyway.

A packaged Linux version as a zip file can be downloaded here. Just use it in the normal way.

Annoyingly you still have to ask for an authentication code even though the network is not real. EDIT: You don’t have to - just make one up.

If you fancy building the Launcher yourself here are the steps I took (basically a fleshed out version of these instructions for Ubuntu / Debian linux)

  1. Install node and npm
    $ sudo apt-get install nodejs npm

  2. Install nvm so you can choose node version 6.5 - not sure if later versions work too, I didn’t try. Possibly you can miss this step.

  3. Install Rust version 1.16.0
    $ curl -sSf | sh
    Follow the instructions and select defaults

  4. Type $ source $HOME/.cargo/env

  5. Download from (or clone the repo). Extract it somewhere, e.g. home folder.

  6. Download from (or clone the repo). Extract it somewhere, e.g. home folder.

  7. In a terminal cd into the safe_client_libs-master directory and run

$ cargo build --release --features use-mock-routing

Make a cup of tea. It takes a while…

  1. Then copy from the safe_client_libs-master/target/release subfolder to safe_launcher-master/app/ffi

  2. In a terminal cd into safe_launcher-master directory and run

$ npm install


$ npm run rebuild-native

  1. Once that’s done, to start the launcher with mock routing run:

$ npm run dev

  1. To make a distribution package use command based on the platform:

$ npm run package

this will generate the package files in the release subfolder.

Have fun :slight_smile: