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:
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.
Last week we started integrating p2p
into Crust
to get more reliable NAT traversal which has been taking longer than expected. It’s mainly due to the differences of p2p
and Crust
semantics. Also, we’re trying to avoid any regression from what was done in themaster
branch and that takes a little bit more care and discussion. In the meantime, some issues in the p2p
crate were noted for future refining and we’re happy to see the Crust
codebase being reduced in size.