We have mentioned a few times recently that scaling the dev team is a significant priority in the near term. With this in mind, we’re delighted to announce this week that we have a new office focussed on front-end development in Chennai, India. Work has already started planning and designing the layout, look and feel. We have an optimistic timescale of 4th December for entry. We do hope to achieve that date all going well.
We have found that while remote working is very effective we also benefit from co-locating Engineers for certain tasks such as; Design, knowledge sharing and training. A well skilled local workforce makes Chennai a compelling choice for rapid team expansion. Krishna will head up the technical side of the office which will already have 4 team members (@Krishna_Kumar, @Shankar, @Srini and @Rachit) when it opens in December and we will recruit as aggressively as we can, without impacting quality.
In addition to building a developer team, the office in India also provides much better access to a large local market. With a population of 1.3 billion and an estimated 462 million Internet users, India has enormous potential, and as the office becomes more established (initial focus will be recruiting) attention will shift more toward marketing the SAFE Network to local app developers. We’ll keep you updated with our progress as we move forward.
This will not negatively impact our recent partnership in MaidSafe Asia, but will compliment such relations with closer technical ability and support being very important to partners. MaidSafe the company will extend its reach in many places over time, we hope. We will use this mix in Asia to test our assertions with a tight budgetary constraint. SAFE will feature very highly in both MaidSafe’s and our partners marketing, but there may be local bespoke solutions that are best handled directly.
Now on with the technical part of the update.
SAFE Authenticator & API
safe-node-app v0.4.1 has been published on npm, incorporating the following enhancements:
- Constants that were internally used by the package are now exposed in the API so client applications can also make use of them. The documentation was updated and you can see more details about these constants here.
- The notification/callback sent upon a successful network reconnection attempt is now generated and sent by the underlying safe_client_libs rather than by safe_app_nodejs.
- The safe_client_libs have been upgraded to incorporate the base64 library update (see the next section below for more details).
The work related to the refactoring of the example apps is almost done. @shankar will be integrating the tests for the web_hosting example and email example app. We will also be focusing on improving the CI scripts for building the example apps and browser. @rachit has been working to set up a scalable project structure for the Java API using Gradle. Once this phase is completed, the API implementation will begin.
The following fixes and enhancements were made to the safe_browser after the alpha-2 release:
- Fix the issue with favicons which are now loaded and displayed for safe:// sites.
- Warn the user upon a network disconnection event in the browser, not only from the Authenticator page but in any open tab, and attempt to automatically reconnect every 30 secs if the user doesn’t explicitly do it.
- Assure that when reconnecting to the network, not only the Authenticator connection is re-established but also the ones for the safe_app plugin and the browser app so the browser state can be saved on the network afterwards.
- Functionality to run tests on the DOM API functions within the browser, and creation of a checklist document for manual testing. The document can be viewed here.
- Fix URI scheme registration for dev mode so the browser can receive authorisation requests even when launched with
yarn start. - Minor enhancement to README for Windows build instructions.
- Fix minor issues when fetching sites with a relative path.
We were aiming at releasing a new version of the browser today with all the above-mentioned fixes and enhancements, but during our internal testing, we found the browser was attempting to connect to the network as soon as it is launched which we don’t consider desirable. We therefore would like to fix this behaviour, which was recently introduced with the enhancements made to the disconnect/reconnect flows, before formally publishing a new version of the browser. We are now targetting a release of the browser for early next week.
@joshuef has been partially working on automating the execution of the browser tests using Spectron, and also looking into scoping Firefox and Brave as an alternative to the Beaker browser. He has summed up his findings in this post on the Dev Forum and we are looking forward to receiving inputs from community members to help us decide the best way forward. We therefore would like to encourage everyone to provide comments and thoughts about this on the Dev Forum.
We are planning to do some more research on the use of WebAssembly and how we can make use of it with our safe_app_nodejs package so that the same API can be used within the browser towards our intention to have unified APIs.
SAFE Client Libs
Starting this week, we are looking into ways to achieve binary compatibility. What this means is that we want apps linked to different versions of SAFE Client Libs to be able to read/write each other’s data on the network. That especially concerns the core apps, like Authenticator: as we improve them, we also modify the app data structures that are stored on the network, and currently there’s no straightforward and standard way to migrate existing data that are already stored on the network to newer versions. However, while we can migrate serialised data and evolve structure schemas, there’s a more complicated topic of evolving core data structures, like Mutable Data, without requiring to restart Vaults, leading to data loss. So for us, it is important to devise an approach that will allow upgrading the network versions without losing the already-stored data. We haven’t yet decided on the approach to achieve this, but we are in the process of intensively researching this topic and soon we will be starting with contemplating a new RFC that should answer these questions and involve the community in deciding which way is the best and what trade-offs we ought to make or not.
The base64 crate version that we were using (4.2) had some security bugs. We are upgrading to the latest base64 version (7.0) in our master branch and we have already upgraded in alpha-2. We also are fixing a bug where re-authorisation of apps was consuming 2 PUTs when this operation should not have been using any mutations. The issue was that we were updating the app container on every authorisation, even if the container already existed and there was nothing to update; now we update it only if it is missing some permissions. In addition, we had raised a PR a couple weeks ago which will be replacing all value structs in our FFI interface with struct pointers. We have updated the PR to change FfiResult to *const FfiResult everywhere in our API, removing the final inconsistency.
Routing, Vault & Crust
The backend team have largely been working on the design of Routing again this week. @bart has mostly completed a refactor of Ewok (the network simulator) to reflect the current notion of the proposed Routing ruleset, which is much closer to the original Data Chains. This refactor of Ewok should help us analyse the protocol, and see any implementation difficulties which might crop up when we’re building these into the real Routing library.
As well as the refactor, there have been several design Hangouts where the reworking of Routing and Vaults has been discussed at length.
The futures-based Crust implementation has been merged into the main Crust repository and is available on the dev branch. Our new Engineer Povilas (@povilasb) has been getting his hands dirty exploring the Crust codebase and asking really probing questions to the team (great to see). He has been extremely efficient understanding Crust and getting the test suite passing again. Work is ongoing porting our P2P NAT-traversal library over to futures+tokio so that it can be more easily integrated with the new Crust.
. Great to see the expansion.
go 
