SAFE Network Dev Update - September 20, 2018


Here are some of the main things to highlight this week:

  • An RFC for Malice Detection was proposed as well as a new Safecoin Alternative Implementation RFC. Have a look at both of these on GitHub.
  • The SAFE Network Fundamentals have been added to the website.
  • We put out a new Medium post on Monday to highlight the release of the updated SAFE Browser and the listing by the ChainRift exchange of MaidSafeCoin.
  • You can sign up here for next week’s SAFE Network: London meetup.


Much of our time recently has been taken with the lead up planning to Alpha 3 and you will start to see increasing amounts of activity in the lead up to that. While the Back End team have been working on the features themselves, Marketing have been collaborating with guys from the Front End to highlight these in ways that not only enable everyone in the community to get involved through a series of releases, but also educate Users about the features while also providing invaluable real-world feedback to the engineering team. Watch this space!

This week, the renewed RFC process kicked off with a bang. One new RFC in particular (on Malice Detection, one way in which the Network identifies bad actors) will be published this week and seeking feedback from the community. To stay updated, please check out GitHub. We are also happy to say that the SAFE Network Fundamentals have been added to the website.

We also put out a new Medium post on Monday to highlight the release of the updated SAFE Browser and the listing by the ChainRift exchange of MaidSafeCoin. After @sotros25 ran another successful SAFE Network: Chicago meetup last week (with @nigel and @joshuef calling into the group by video to discuss all manner of things Front End), next week it’s the turn of @opacey and the SAFE Network: London group - you can sign up here. And finally, this weekend, @dugcampbell will be in Maratea, Italy speaking about the SAFE Network at the Heroes Conference, hopefully in weather conditions marginally better than those experienced in the West Coast of Scotland this week.


Earlier this week we deprecated our Beaker-based SAFE Browser, and we merged all the code from the peruse branch onto the master branch of the safe_browser repository. The documentation for the new DOM API exposed by our now Peruse-based SAFE Browser has been published in a new section in the README document itself. We have also updated the master branch of our Web API Playground tool to make it compatible with the new SAFE Browser v0.7.0.

With the JNI issues out of the way, all the safe_app_java APIs are now working on Android. We now have a working Instrumentation test setup both locally and on Travis CI. We will soon be starting to work on example applications for Android and documentation for the same.

The SafeAuthenticator mobile repository has been refactored. A PR to refactor the safe_mobile repo (now renamed to safe-email-app-csharp) is under review.

SAFE Client Libs

This week we have been focusing on integrating our SAFE Crypto library into SAFE Client Libs (MAID-2725) to replace rust_sodium there and to standardize our cryptographic facilities. As part of this work, we needed to implement missing functionality in SAFE Crypto that was required by Client Libs, such as the ability to specify custom nonces during symmetric encryption, the ability to generate keypairs from seeds, and the ability to derive a key from a password and a salt.

We also have been continuing to work on the Java/JNI enhancements. We found another error that was hiding there: it turned out that the JNI library that we use, jni-rs, contained a subtle bug related to JNI threads attachments and detachments.

As you might already know, JNI is used to communicate with the native code (such as code written in C/C++ or in Rust). This process is fairly straightforward when Java calls Rust functions but because SAFE Client Libs provides an asynchronous API based on callbacks, we also need to call Java callbacks back from Rust. To do this properly, JNI provides a couple of special functions named AttachCurrentThread and AttachCurrentThreadAsDaemon (the difference between them is that during shutdown Java VM will not wait for daemon threads to finish). Both are used to call into JVM from native code and these functions are usually called right before referencing Java classes. It’s also important to do the cleanup, so developers need to call DetachCurrentThread when the call is completed; and that’s where the bug was hidden: while in jni-rs the thread was detached automatically using RAII for AttachCurrentThread, it wasn’t the case for AttachCurrentThreadAsDaemon. Because of that the JNI code that used AttachCurrentThreadAsDaemon specifically leaked memory and had erroneous behaviour, just as in our case. We fixed this in our code and also provided a pull request with a patch for the upstream version of jni-rs.

In the end, this should conclude the work on making our Java/JNI bindings solid and robust and we’re quite happy with the result. This opens the road for the mobile team to make cool example apps - exciting times lie ahead! :slightly_smiling_face:


This week, the functional test framework we have been taunting for a couple of dev updates finally reached completion. We already started battle testing it with the testing of dynamic membership features and used this to iron out a few kinks in it.

The Routing team’s main focus has been to test the dynamic membership part of PARSEC that was recently coded. These tasks are already bearing fruit as they helped us catch a few mistakes in the exact way we implemented peer addition. The best kind of mistake in code is a mistake caught early as it can be rectified at a reasonably low cost, which is what we have been doing.

We are also putting some effort in improving the previous integration testing code to allow easy integration testing of dynamic membership features.

So to sum it up, the entire team has been working on testing of dynamic membership features of PARSEC from a number of different angles and the testing has already proven useful. We expect to remain mobilised on this general goal next week, with probably a few of us getting freed up to push the malice handling forward in parallel.


thanks for update. Few notes> why still no news on recruitment process, also when can we expect the whitepaper for dynamic membership?


For anyone struggling to find the RFCs, here are the direct links:


Recruitment is ongoing and never stops. There is news many weeks.

That is an addendum/appendix to the existing whitepaper.


Good, solid progress! Keep it up guys!

I particularly enjoyed the alternative safecoin RFC this week. Good to see it getting closer to implementation!


We updated on this a couple of weeks back and as David mentioned we’ll keep you let you know as things change.


It was great chatting with @Sotros25 and all in attendance at the meetup. They had some great questions and feedback, a few of them that have dipped their toes in other crypto projects and had some genuine interest in the benefits of developing on the SAFE Network. @joshuef gave a really inspirational talk about developing for SAFE that felt was a great theme for the meetup. Thanks for the invite!

Can’t wait to see PARSEC get put through the paces! Another great update @maidsafe!


Steady as she goes for now, Lee Ho when the the time is right and a good broad reach thereafter…


Great update! Glad to see the steady progress. I hope everyone around Edinburgh is fairing well given the inclement weather!

Many thanks to @Nigel and @joshuef for joining SAFE Network: Chicago on Saturday! They shared so many great insights and fielded tons of questions on SAFE front end development! The whole group really appreciated getting their perspective. They inspired discussion on not only dApps we’d like to see developed on the SAFE Network but a tactical discussion on how to reach and get more developers on board. More to come… If you’d like to join us remotely for a meetup—presenting or listening in—let me know! :smile:

Btw, if anyone happens to be in Oxford over the next couple of days, let me know.


Good luck in Italy @dugcampbell You have a way of succinctly describing the network that people can grasp and take home to share with others. A lot of good news to present!


good stuff, as always!
one question: it’s gotten very quiet around the India office.
I was expecting most new hires to start over there actually. Any news?


@Sotros25 Community member of the month nomination


The Malice RFC looks like it will be a great addition to the network.

There are so many levels of detail that Maidsafe is addressing that go beyond what other projects seem to consider - albeit the Safe Network itself goes far beyond other crypto projects so that needs to be par for this course.

What I am starting the believe though, is that as the details are built and word of mouth continues to spread, I can really see more and more of the crypto community as well as the coding community at large start to take this project much much more seriously over the coming couple of years – meaning that most other projects will begin to look pale, thin & weak by comparison and that will be a really huge deal for all that have invested their efforts into the project – especially the team @ maidsafe!!

Great job guys, keep plugging - that pot of gold is getting closer with each passing week.


Thanks Maidsafe devs for another great update.

:clap: @anon86652309 you created the first super "Safecoin Alternative Implementation"yan. :face_with_monocle:

If it’s not to much asked could you merge the example application with the SAFEAuth? Eventually all SAFE apps will come with the SAFEAuth baked in, so that you don’t have to download two apps, but it would be nice to see it in action if possible.



We tend to announce the new recruits as they start with us but I can confirm that we have 1 new team member joining next week, and another 6 starting in December, so the Indian office is starting to fill up nicely. We’ll introduce the new team members in due course


Hi all,

Just following up on the RFC news…

RFC #50: ‘Transparent Malice Handling within PARSEC’ is now agreed and available to view and comment on (there’s a new discussion thread on the forum). Here are the links:

:books: RFC Document

:writing_hand: Discussion Thread (SAFE Network Forum)

RFC 50 - Transparent malice handling within PARSEC



Team is growing. Project is progressing. Looking good team Maidsafe. :blush:


Never in my life did I think I would see someone drop a DBZ reference in a dev update :laughing:


Awesome update! This is my favourite part of the Safe Network fundamentals:

“The countdown to the new Internet has begun. Try, test, build, contribute. Be part of it.”

History in the making. Cheers!


ill drink a bit for the devs today, live long!