We have progress to report in a number of areas this week with the front-end team delivering a few upgrades. As you will see, the SAFE Browser v0.8.0 is being tested internally, along with new versions of the Web Hosting Manager and the Email app having incorporated the latest changes from safe_app_nodejs and safe_client_libs . These will be pushed out just as soon as we have verified they are working correctly. The new custom browser Proof of Concept (PoC) is also going through internal testing and while basic seems very functional.

The Routing design discussions continue with particular focus being given to managing section merges with the integration of Data Chains. The team continue to consider edge cases to cover as many scenarios as possible. It is much more efficient for us to plan this stage very carefully as moving to code/tasks too quickly and failing to consider a particular event will only cost us more time in the long run. Things are moving in the right direction, there is skeleton code in place as a baseline and we hope to have more progress to report soon.

SAFE Authenticator & API

We finished making the required changes in safe_app_nodejs to upgrade to the latest code from the safe_client_libs and system_uri libraries, and we were able to successfully package and publish v0.5.0 of the safe-node-app package on npm for the first time using the automated scripts. This new version exposes some new useful functions in its API for applications to not only generate sign keys but also sign and verify content with them.

Both the safe-app and safe-authenticator browser plugins were also updated to work with the latest versions of safe_app_nodejs and safe_client_libs , and they were also packaged and published on our S3 servers with the new automated CI scripts.

A new version of the current SAFE Browser, which makes use of the latest packages mentioned above, has been made available today for internal testing. Tests to make sure that current data in the Alpha 2 network is still accessible after the changes we made in our packages need to be performed. This is also the case for new versions of the Web Hosting Manager and the Email app which are also going through an internal testing phase.

The first and early-stage version of the custom browser has also been made available today for internal testing. Even though some aspects of the UI are still very basic and functional, this first version is already allowing the user to log in to the Alpha 2 network, browse safe:// websites and authorise standalone applications with its embedded authenticator, just like our existing SAFE Browser & authenticator. We are performing tests on all platforms so that we can share it with the community ASAP.

Some of our next tasks are related to moving forward with the automation of our release process, focusing now on automating the packaging and publishing tasks for the browser on all supported platforms, with versions for mock and non-mock routing. We are also resuming some other activities in relation to enhancing our tests’ code coverage in safe_app_nodejs as well as some internal refactoring of the package.

The existing APIs in safe_app_csharp are being updated to work with the safe_client_libs master branch. safe_app_csharp currently supports the mobile iOS and Android platforms, we are also working on adding support for the desktop platforms which should be live soon. We are also working on expanding the test cases for the existing APIs. JIRA tasks were created for adding the missing APIs to complete the safe_app_csharp library.

The progress in Java APIs has been more focussed on packaging and distribution practices. @joy will be using the Java bindings to start wiring up the APIs from early next week.

SAFE Client Libs

We’re making progress with language bindings: this week we produced first results for both C# and Java/JNI. This hits a big milestone but there are still some small things to be completed. First, JNI structures have to be mapped to our native Rust structures. Second, C# bindings need to be accommodated to Xamarin to work on mobile platforms (and on iOS especially, as this platform has some extra requirements). After we’ll be done with that, we’re going to work closely with the front-end team to improve upon the generated bindings and produce some small working examples of the API usage; we’re expecting this to happen early next week. For Java, we’re also working on merging some changes that we made to the JNI library to the upstream.

In parallel, @marcin has been working on improving SAFE Client Libs’ nuts and bolts. After we made this change to the way URIs work in the inter-process communications between apps and the Authenticator:

MaidSafe Dev Update :safe: October 5, 2017 We stopped prepending schemes to URIs so that the SAFE Client Libs are decoupled from the URI scheme and only concern themselves with payload encoding/decoding

there was no apparent way to provide an unregistered app ID within a request, so the front-end part of the Authenticator didn’t really know where to send the response. This has now been fixed by making it possible to put arbitrary data (including the app ID) along with the IpcReq::Unregistered request.

Another function that SAFE App API lacked was a routine to get a name of an app’s container. This introduced unnecessary hardcode on the front-end side and complicated usage of testing functions which create apps with random names. The deficiency is fixed by this PR. Testing functions have also been updated to follow our API convention.

Routing & Crust

The Routing efforts are still mostly behind the scenes. We have been continuing to detail how the network will be handling section merges after the Data Chains are introduced. It is especially challenging to figure out how to handle various network events that could happen during merges, and for that we have been considering multiple possible scenarios, exploring what could go wrong and how to prevent it.