Last week, we talked about potentially adding a temporary data persistence solution to client-only networks (testnets where MaidSafe manages all the Vaults). The advantage of implementing this feature is that the front-end team and app developers would be able to start gaining experience with versioned APIs, versioned data, backward compatibility and deprecating APIs before data republish gets implemented via data chains. But based on what we heard from the community, we’re going to drop any plans to support this immediately. We can revisit scoping options for this if we have too many short testnet iterations causing data wipes, since this probably wouldn’t be a great experience for app developers.

Developers who want to try out the new SAFE API can use the SAFE Browser binaries built with mock routing. See also the documentation for the Node.js API and the DOM API as well as the following example applications:

SAFE Authenticator & API

We updated the safe_app_nodejs API based on the recent changes in the dev branch of safe_client_libs. The changes in safe_client_libs address a few inconsistencies and include a couple of API changes as mentioned in this pull request. @bochaco also expanded the example snippets in the DOM API documentation. A few minor bugs were identified while creating simple code snippets and have been fixed. We’ll update the API docs at the same time we release new safe_browser binaries, but devs who want to see the latest DOM API documentation can build it locally via the beaker-plugin-safe-app repo.

@kumar has been away for this week and, as a result, the progress with the Java API has been slower. We had cross-platform issues while running the test cases. The issue was with the FFI callbacks being garbage collected. The issue is fixed now and the tests pass across several platforms. We will be wiring up the MutableData and NFS API next week.

Based on the community’s request, we will be releasing signed binaries from now on. We are planning to release these for the browser and also for the web hosting example application. We hope to provide signed binaries early next week which would include all the latest changes.

SAFE Client Libs & Crust

We are close to done with updating the master branch of safe_vault to latest routing (in this pull request), including changes like Serde 1.0 and SHA-3. This is currently the single remaining library that needs these updates, good news and nice to see the end of that road.

With help from the front-end team, we continue to polish safe_client_libs and apply a few more fixes and tidy up some of the code. Lately we discovered some inconsistencies in NFS functions available to user apps: they don’t work as expected (e.g., not updating last modification time) and this behaviour is not documented properly. So currently we are in the process of reworking the set of NFS functions in safe_app to match the API available to Rust developers in safe_core::nfs .

@bochaco has discovered several bugs in the DOM API that are possibly rooted in safe_client_libs and we are looking through these cases, we’re also trying to find a more efficient way to debug such problems in the future.

Routing & Vault

The simulation for option B is making good progress with most of the routing team working on that this week. The initial results covering adding, removing, splitting and merging look promising. We are making a few small improvements to make the simulation more accurate, and also slightly extending the option B proposal itself, specifically:

We need to cope with the fact that we can have several “contradictory” valid, current blocks affects safe_vault, and how data can be handled given that kind of uncertainty.

The document assumes that we have a mechanism that guarantees that eventually, every node receives every vote that concerns it. That will also need to be designed in detail.

We also applied a few tweaks to the rules to make them less ambiguous and to address some scenarios we came up with independently of the simulation. The forum post has been updated.

In routing master, we fixed a potential problem where two parallel merges could cause nodes to go out of sync.