Summary

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

MaidSafe Loan Application Update

The response to the MaidSafe loan application has been overwhelming, within 24 hours we saw the initial offering of 10 million coins oversubscribed by more than 24 million!

The offering was doubled to 20 million considering this and the allocation spread over all 41 applicants.

We can confirm 39 transfers have now completed; 1 applicant is no longer able to proceed, and 1 was given additional time due to personal circumstances.

Which means we have received to date circa 19.8 million MAID from our community. The level of support from you is truly humbling, thank you!

Vaults Phase 2

Project plan

Both @qi_ma and @jonhaggblad have started working on Vaults, and have already made some important changes, serving also as a good introduction to the code.

Qi changed Routing to expose its mock quic-p2p facility. This change allowed to remove the redundant mock code within Vault.

Jon and Qi also started on using real Routing in Vault integrations tests, with mock PARSEC as the first step. So far there is an issue with the testing network setup, which we are progressing in resolving. When it’s resolved, this feature will greatly simplify tests of different network configurations. With mock PARSEC we can automatically set up a network without following thorough processes required by the real network which are not really necessary for testing. This feature already exists and provides a lot of value in Routing, and we’re looking forward to using it in Vaults too!

In parallel, @ustulation and @nbaksalyar continue to work on implementing a new handshake scheme. It is a required step to support clients bootstrapping to a full network comprised of multiple sections and many nodes. Currently, we are implementing tests for the new handshake process.

Last but not least, we released SAFE Vault v0.20.1. It includes some of the recent changes, and you can use it to run a Vault instance locally on your machine. A full list of changes can be found in the changelog.

SAFE API

Project plan

We are very pleased to share our new release of the SAFE APIs and CLI (v0.6.0) today! This release is an interesting milestone as it’s the first release of the Authenticator daemon (safe-authd), which means we are now deprecating the safe_auth CLI, and all operations can be performed from a single interface: the SAFE CLI.

You can upgrade to the new version using the $ safe update command if you have a previous version in your system, or otherwise just download it from the release page linked above.

The CLI User Guide was updated with detailed instructions for the use of safe-authd with the CLI. Note that this version of the CLI and authd requires the latest version (v0.20.1) of the SAFE Vault, so make sure you have this new version if you want to run a local vault.

During the last few days, we were able to also include in this release a new feature which allows switching networks/vaults using the CLI. This is very useful for users who run a local vault and also use the shared vault hosted by MaidSafe, allowing to switch back and forth between them. The updated User Guide also includes specific details on how this command works, so please refer to the Networks section of the User Guide to learn about it.

A new version of the safe-nodejs package (v0.6.0) was also published which upgrades its dependency with the safe-api . This new version allows SAFE Node.js applications to send authorisation requests to the Authenticator daemon using its new communication protocol (JSON-RPC over QUIC) instead of the system URI mechanism we’ve been using up until now. Although this is all transparent to the application as it’s all being taken care of by the same auth_app API.

Defining the Minimum Viable Experience

We often bandy about the term Minimum Viable Product (MVP) when trying to describe what we are working on, and what is left to be done before the inception of the living breathing autonomous network. That day.

But with many strands of work, different teams working on different layers of the Network, this term can be the source of diverging understanding, and confusion.

So let’s lay it out here.

What we are talking about when we talk about an MVP are the features required for a functionally complete network that delivers full data retention and delivers on the security promises. This is the network infrastructure that underpins all other functionality.

When we have an MVP, we can have a Network.

To the average user though, it’d likely be quite raw, need only a basic interface via the command line, and not necessarily even consider the basics of usability, such as human-readable URLs, as one example.

We need to go further than that if we want the Network to be buoyant enough for a successful launch. For that, we also need to build a Minimum Viable Experience (MVE).

The MVE is made up of features and applications that are necessary for our initial, early adopter user base to be able to practically use the network, taking into account their experience, needs and expectations.

The SAFE Network App is a conduit to this MVE. It’s minimal, lightweight, and attainable, but it encompasses all we need to get the network to stand up, in the most efficient route, and then iterate from there.

So this week we’ve been gathering the teams for a series of, quite frankly, vocal nodule inducing hangouts to button down and clear the path to MVE, and what comes after.

Over the coming week or so we’ll be sharing this, so we can paint the picture of how it will all hang together, and you can see how we’ve cut down to the essentials, identified the stretch-goals, where community apps can help out with some of the desirable features that didn’t make the MVE cut, and how this all paves the way to the Network we’ve all dreamed of.

Flat Data and Labels

In amongst all our development work and UX explorations, the question of data structures, and the possibility of having a flatter data structure has come up a few times. As such we’ve been exploring this idea in the Labelled Data pre-RFC thread.

The idea is similar to how we’ve imagined ‘containers’ for apps previously but increases flexibility while still giving app developers easy ways to discover/manage application data. If it works as intended it should also serve to prevent silo-ing of user’s data in application containers (think two different photo-apps being unaware of the other’s photos), while achieving some other much-needed MVE functionality (general indexing of user data).

That’s the gist anywho. Head over to the forum thread to dig into the detail. It’s a valuable discussion that will help inform the exploration of the idea and allow us to put forward a concrete proposal and RFC.

SAFE Client Libs

Project plan

As of PR #1102, rust_sodium is now fully deprecated and the SAFE Client Libs are now void of direct C dependencies . The various cryptographic mechanisms previously used from rust_sodium are now ported to native Rust crates such as threshold_crypto and miscreant. This gives the consumers of SAFE Client Libs a hassle-free experience without the pain of handling C dependencies. This also opens the doors to support of new platforms such as MUSL and wasm which were previously blocked due to this painful (yet quite useful) dependency. With that major chunk of work off the table, the team will now be focussing on the technical aspects of the labelled data proposal and the Phase 2 vault. In parallel to this, the team also prepared and released a new version of the Client Libraries. Note that this release does not have the latest changes in the master branch. The release was done from an older revision that is compatible with the SAFE CLI. So keep an eye out for a new release, one without rust_sodium .

SAFE Network App (desktop)

Project plan

We’re happy to be sharing our first beta channel release! As a beta, it’s more stable than our alpha releases (which some folk may have noted, there have been many of…), and it fixes a few issues reported by the community on Windows, as well as some other bumps that we discovered in the release/update process for both the SAFE Network App and the browser.

As such, if you want to stay on the beta channel (and only see the more stable beta releases), you should download that from the GitHub release page. Otherwise, if you want to be on the cutting edge with alpha releases, you can grab alpha.20. You will need to download it again though, I’m afraid. Due to the aforementioned auto-update issues.

It’s been quite pleasant to be able to thoroughly test the update functionality of the SAFE Network App and be more confident in our release processes due to the update channels, so that’s great news. We’ve also further improved workflow using GitHub Actions and will continue to do so.

The only other notable things from this release are that the SAFE Network App now will have a channel named executable (e.g. SAFE Network App Alpha ) and that the channel version will work with the same channel of apps. So SAFE Network App Alpha , will download/manage SAFE Browser Alpha . This seems to make sense and helps remove some elements of doubt when working across release channels.

It should be noted for Ubuntu users, we’ve seen issues around libsodium linking with the latest 19.10 update. There’s no fix coming from our side for this as libsodium is being removed across the board soon! Which means this will hopefully be the last release to have these issues (there are similar things previously noted for macOS Catalina). But in the meantime, you should just need to ensure some version of libsodium is available at the location indicated if you come across this issue.

SAFE Network App (mobile)

Project plan

This week we targeted some of the issues from the project board and added a few new screens to the app for the corresponding tasks. The newly added pages include the login page and the create account options page. We updated the app to provide basic navigation functionality and integrated all the existing pages to the navigation flow.

Currently, we are focusing on adding new pages and implementing their layout along with all the required controls for a screen to work properly. The styling and user interaction related tasks/issues will be worked on later.

SAFE Browser (desktop)

The browser too has an update with the new safe-nodejs package. SAFE Browser v0.15.4-beta.1 can be downloaded here. Alongside the API updates, this release has the same workflow improvements as the SAFE Network App, in terms of GitHub Actions, as well as some minor dependency updates and other CI changes.

There is also an alpha release available here.

SAFE Browser (mobile)

Project plan

We updated the mobile browser to support Android 10 and refactored some of the native Android code to use the new platform APIs. We will be updating the iOS support to the latest iOS version next week. We updated multiple outdated dependencies as well for better performance and less bugs. Once all the changes are done, we’ll be testing a complete app to ensure the proper working.

SAFE Authenticator (mobile)

Project plan

We updated the authenticator app to use the latest safe_authenticator native libs from the SAFE Client Libs. We also removed the bindings code for all the deprecated APIs.

The mobile authenticator app now shows the test coins permissions in the authentication request dialog. The same changes need to be reflected on the app information page. We will work on those changes next week.

We also made some minor changes in the vault connection file manager option to make it more user-friendly and easy to use.

Node Ageing

Project plan

The work on promotions (adults to elders) and demotions (elders to adults) (PR 1929) has been progressing steadily. We identified and fixed a number of issues thanks to our extensive test suite. There seem to be just two major outstanding issues before this work can be merged to the fleming branch.

The first one is about a node trying to join a section that’s undergoing a split. The join request messages can end up in two different sibling subsections, thus the sections do not reach consensus. We have already a solution to this and it is currently being finalized.

The second problem is that when a node gets relocated, not every other node realises it immediately (due to the eventually consistent nature of the network). So some nodes might still think it is a member of the original section and expect it to participate in the message delivery as such. We don’t yet have a clear solution to this problem but several have been proposed and discussed and we seem to be on the right track to cracking it.

BLS

Project plan

Aside from some progress on signature combination being correctly handled, we’ve paused work on these issues and PRs to focus on Node Ageing and Vault until (PR 1929) can be merged.

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