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 safenetwork.tech 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 safenetwork.tech 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.
SAFE API & Apps
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.
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
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!
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.