Summary

Here are some of the main things to highlight this week:

We released Baby Fleming iteration 2 This update consists of a new version of the safe_vault binary (v0.22.0) which removes the PARSEC step for client requests.

We released SAFE CLI v0.10.0 which includes (among other improvements) a new files tree command.

command. We released a new RC MaidSafe.SafeApp NuGet package that supports doing range requests and interacting with the Baby Fleming network.

Vaults Phase 2

Project plan

Today we are releasing the second iteration of Baby Fleming, aka Vaults Phase 2a

As detailed in last week’s dev update, the performance issues in the first iteration of Baby Fleming were primarily due to all client requests that involved the spending of safecoin being sent through PARSEC to reach consensus before processing the request further. Iteration 2, which we have released today, contains the removal of the PARSEC step from the client request-processing flow.

We will of course still need to reach consensus in this flow and that is where BLS - Distributed Key Generation will come in to ease the load on PARSEC. More on this in the BLS - Distributed Key Generation section below. For now though, it makes sense for us to remove this performance restriction to allow you (and us) to test Baby Fleming.

How do I update to Baby Fleming iteration 2?

This update consists of a new version of the safe_vault binary, v0.22.0.

Using the CLI, you can install this new version with the safe vault install command. See the CLI readme for full instructions on installing the vault, as well as full instructions on running your own section of vaults on your platform.

Known issue

You may experience intermittent failures ( AccessDenied or NetDataError - Failed to PUT Sequenced Append Only Data logged here) when uploading data. We are aware of this and we are investigating.

When will MaidSafe be hosting a Shared Section?

Our intention is to host a Shared Section as soon as testing shows the sections are steady, with the major bugs resolved.

Note that when we create a Shared Section we will be taking down the current Shared Vault - data will not be transferred from the Shared Vault to the Shared Section.

SAFE API

Project plan

We’ve released a new version of our safe-api (v0.10.0), as well as a new safe-cli (v0.10.0) which includes all the features we’ve implemented since the Baby Fleming release. We’ve updated the CLI User Guide with instructions for the new files tree command.

This new version of safe-api is the first version which exposes its API as async , which is an important step towards fully supporting asynchronous calls from these APIs. As mentioned in previous dev updates, internally they are still not asynchronous, and that’ll be our next step in this regard.

The mobile libs build for safe-ffi were disabled for the last couple of weeks. The issue was related to the mobile support for some of the external Rust crates. This week, we resolved the build failure for safe-ffi in a separate branch ( baby-fleming-mobile ). Once we have the stable versions of the external crates working with our own libraries properly we will merge the code with the master branch. These updated libs will help us support the release of the mobile apps for the single-section network.

We’ve finalised a basic set of benchmarks to be running against a Baby Fleming network. These tests are simply PUTting data onto the network (files of size 0.5, 1, 2 and 4 megabyte). The tests will run these X times (looking for a sane sample size hopefully at least ~50 times), though this will depend on the progress to improve data PUTs in general. For those interested in running this (or contributing more tests), you can check out the draft PR which adds a -t or --test argument to everyone’s favourite safe vault run-baby-fleming -t to automatically start the network, re/start the authenticator and create a test account for the CLI. (Note, this needs both the safe command and authd to be installed in their standard locations).

SAFE Network App

This week we’ve been working on some small improvements to the SAFE Network App, updating our Node.js dependency to get ready for a Baby Fleming compatible release, and straightening out the E2E testing.

The Node.js update has highlighted some potential bugs there, so we’re looking into that. But once we have that sorted, we’ll be able to get this out to play nicely with

SAFE Authenticator / SAFE Browser (mobile)

Authenticator board, Browser board

This week we updated the Authenticator app to support the Baby Fleming network and tested the app on both platforms (Android, iOS).

We also released a new RC MaidSafe.SafeApp NuGet package today, to enable us to update the Mobile Browser to support Baby Fleming. We are currently testing the Mobile Browser app internally and will be releasing new updated versions of both mobile apps once we are happy with them.

SAFE App C#

Project plan

Last week the Rust fetch API was updated to support fetching a range of bytes from a file, so this week we updated the fetch and get_immutable_data C# APIs to also support range requests. This will allow devs to fetch the content between the given start and end index. We also released a new RC MaidSafe.SafeApp NuGet package. This new package provides support for the single-section / Baby Fleming network.

Routing and quic-p2p

Routing Project Plan

This week we merged the improving message delivery in the presence of lagging nodes work PR (PR 2068). Other major progress achieved includes merging the work of simplifying the state machine: making Elder and Adult into Approved (PR 2071), as well as BoostrappingPeer and JoiningPeer into one (PR 2072). These simplify the state machine a lot, and we will eventually be looking to remove the state machine altogether. Another improvement this week was the merging of the logging identifier PR (PR 2073). This reduces our code and ensures that all logging in the Routing crate identifies the node the log entry was for.

We are also starting to think about conducting some more quic-p2p tests to have better data about its scalability and resource requirements. We expect it to handle hundreds (or even thousands!) of connections at once and it’s important to know the limits and plan for them accordingly, to make sure the network systems will not be overloaded. We are planning to start these tests after the new release which will include the IGD support and the latest QUIC protocol implementation improvements from Quinn, the underlying networking library we use.

BLS - Distributed Key Generation

By depending on PARSEC, the spine of the network, for all types of consensus we might just stress the network from perspectives that we don’t usually see. For example, data in the SAFE Network can be fast-changing and querying/fetching such data with consensus from PARSEC would take a while to be retrieved. This duration might just be enough for the data to get updated to a newer version from the fetched one. Therefore, to minimise loads on PARSEC and to achieve quick consensus for operations like querying of shared data, multisig wallets, etc., we face the requirement to sideload some of the consensus onto another mechanism. In here comes BLS-Distributed Key Generation, a cryptographic threshold signature scheme, that allows entities to attain consensus on some object swiftly via the nature of its six phases and forcing 100% participation from the corresponding nodes. You can read more about its workings and details here and here. A PoC implementation is in the works by the team that would be tested on shared data by clients initially, although the bigger picture is to use it for cases like the ones mentioned above and would be a generic crate that will be used for attaining consensus without completely relying on PARSEC at all times.

Useful Links

Feel free to send us translations of this Dev Update and we’ll list them here:

As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the SAFE Network together