SAFE Network Dev Update - February 20, 2020


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

  • Testing of the cross platform safe-network-launch-tool is well underway.
  • In preparation for the first Phase-2 testnet, we’ve started adding a new set of subcommands to the CLI to allow users to install safe_vault on their system ($ safe vault install) and also to be able to launch a local single-section network with a simple command (e.g. $ safe vault run-baby-fleming).
  • We’ve been discussing CORS and its place on the SAFE Network over on the Dev Forum.

Vaults Phase 2

Project plan

Some minor but needed improvements are being made around the options for vault logging. We’ve been working on a couple of PRs to provide the user with options to send logs to files.

As mentioned last week, we started creating a simple tool which will make launching a local (single-section) test network very easy. We’ve made good progress and we are now performing some tests on all platforms and trying to add some simple user guide documentation.


Project plan

Since the announcement of the Rust v1.39 release introducing async/await expressions, we’ve been working in parallel and with low priority on trying to migrate the safe-authd codebase to the new async/await style. This week we were able to finalise that work in our safe-authd and jsonrpc-quic crates, translating all logic where Futures were being used with simple async expressions. This, as expected, has simplified the codebase of these two crates massively, and allowed us to also start making a better separation of concerns between the jsonrpc-quic and safe-authd crates. This also allowed us to update the quinn dependency to its latest version (v0.5) which already exposes its API with async functions.

We will continue with this migration now on the safe-api crate itself, again as a low priority task and in parallel to the other tasks we are working on, to eventually be able to have async APIs in Rust and in the Node.js bindings with Promises.

In preparation for the first Phase-2 testnet, we’ve also started adding a new set of subcommands to the CLI, this time not only to allow users to install safe_vault on their system, but also to be able to launch a local single-section network with a simple command.

We’ve been able to create a first draft implementation and we are testing it on all platforms. Even though it’s already functional we are making some enhancements to ensure the UX is as good as possible. Just to give a glimpse of what we are aiming at, to launch a local single-section network with the CLI, first safe_vault would need to be installed in your system with $ safe vault install, followed by a second command to launch the local network, e.g.:

$ safe vault run-baby-fleming
Storing vaults' generated data at ~/.safe/vault/baby-fleming-vaults
Launching local SAFE network...
Launching with vault executable from: ~/.safe/vault/safe_vault
Network size: 8 vaults
Launching genesis vault (#1)...
Genesis vault contact info: [""]
Launching vault #2...
Launching vault #3...
Launching vault #4...
Launching vault #5...
Launching vault #6...
Launching vault #7...
Launching vault #8...

Labelled Data, Indexing and Token Authorisation

RFC, Tokens RFC, Project Plan

The last week has seen steady token progress. With our updated Token structs and caveat verification getting implemented in vault mock tests and finalising another PR updating our AppKey storage from the authenticator, to store AuthTokens too. This means we’ll now be able to reissue tokens from the authenticator, without having to ping the user again.

As we finish off these last reviews and milestone, we’re also starting to look more deeply at the next steps towards labels. So we’ve started some planning on what aspects to tackle next, and will likely be updating a labels RFC shortly with information on that, before we start firing in there.

SAFE Browser (desktop)

Project Plan

On the back of some work the community developers have been doing, we’ve been discussing CORS and its place on the SAFE Network over on the Dev Forum. With that in mind, we’ll soon be working up a new SAFE Browser alpha with updated dependencies and permissive CORS, which should hopefully make it easier for web devs to get going on the SAFE Network :+1:

SAFE Browser (mobile)

Project Plan

Last week we released a new version of the SAFE mobile browser which provides the pWeb experience on mobile. Since the release, we have been closely following the forum release thread and looking into the issues reported by the community.

We migrated all the issues from the thread to Browser GitHub issues so they can be tracked and tackled.

We’ve already fixed and closed some of the issues from the list, including the address bar safe label animation freezing on iOS, and an authentication issue which was prompting the user to allow the Browser app multiple times before it eventually returned to the authenticated Browser and let the user continue. Investigation into other reported issues continues.

SAFE Authenticator (mobile)

Project Plan

As mentioned in the SAFE Browser (mobile) section, we have been closely following the forum release thread and looking into the issues reported by the community regarding the SAFE Authenticator (mobile).

We migrated all the Authenticator issues from the thread to Authenticator GitHub issues so they can be tracked and tackled.

A common theme from the feedback was that the user interaction on the vault selection page was not quite as intuitive as it should have been, so we spent some time discussing, developing and trying different UI solutions to improve. An update has now been merged upstream and you can have a look at the new page design in this PR. We also fixed a couple of other reported issues including one issue related to the mobile device’s dark theme overriding the apps own settings on iOS and therefore making some screens unreadable, and we enabled scrolling on the Login page to cover for smaller screen devices having the login button hidden by the on-screen keyboard. We will continue investigating the other issues reported.

The feedback received for the mobile Browser and Authenticator has been invaluable and we would like to thank everyone who took time from their own busy schedules to help determine how we continue to shape these apps, and the SAFE Network :heart:


Project plan

To keep the mobile apps and packages progress in sync with the CLI and desktop apps, we have already started to test the APIs to work with a single section network. We faced some issues related to the native libs generation for the mobile devices when different repos (safe-api & safe_client_libs) were updated to use the new Rust crate versions. With the help of the SCL team, we were able to figure out the issues and we are back on track.

Based on the testing so far, we believe there won’t be too many changes in the APIs before we will be in a position to release the updated packages and apps alongside the new native libs.

Safecoin / Farming


This week, we built on the signed orswot proof-of-concept discussed last week by forking the rust-crdt crate to integrate signatures more deeply into the data structure itself. Some challenges remain, but it seems a step in the right direction.

Routing and quic-p2p

Routing Project Plan

We’re continuing to make significant improvements to our networking library, quic-p2p. The first thing we’re looking to address is IGD support. IGD (Internet Gateway Device protocol) is used for UPnP in home routers; it allows users to automatically enable port forwarding for applications that need it, such as VoIP, game servers, and – of course – peer-to-peer networks. And as the Crust test results have shown, there’s a surprisingly large number of home routers supporting this protocol and it really helps to simplify home vault setup. We previously had IGD support in Crust and so we are looking to port this implementation over to quic-p2p.

Another important thing for quic-p2p is the echo service support. Every vault has a built-in echo server that allows clients to find their public IP address, which is an important step for joining the network. However, the current quic-p2p client code has a limitation: it uses only one address from the list of contacts to send such a request. In the case where that address is unresponsive (e.g., due to a vault being offline), the query would fail. What we want instead is something similar to the bootstrap process: query all of our contacts all at once asynchronously. This way we would achieve much more robust results and better performance.

@lionel.faber is also working to make sure the networking works well on mobile devices. He sent a patch upstream to quinn, the Rust QUIC protocol library, to fix problems he’s found on iOS-based devices.

On top of that, we’re also looking to simplify the quic-p2p API for developers using the library. All of these changes should go into the next release which we are preparing now.

On the Routing side, we are continuing work to improve gossip - which is the mechanism by which nodes exchange messages in order to reach consensus. As mentioned in the previous dev update, we removed the artificial delay which was slowing the gossip down. This means we can now reach consensus faster, but we are facing a new issue - we now create too many gossip messages and they can quickly flood the network. We are currently working on solving this problem.

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 :tada:


First! amazing… for once…


Second wooohoo!!! Now to read :smile:

I’d like a Baby Fleming stuffed toy, please. I imagine it’ll be even cuter than Baby Yoda and Baby Groot put together. (Merchandising opportunity, anyone???)

Exciting to read about all the great updates! Keep ‘em coming :smile:


Third nerd :innocent: Now read

Thanks for the update Maidsafe devs.

With commands like: $ safe vault run- :baby: -fleming
It becomes tempting to try CLI :sweat_smile:

Super exited for the test net :exploding_head:


4th but I have actually read it :slight_smile:

– said he in a passive-aggressive manner. Perhaps even Mr Cheesy Numbers would agree this is significant progress and bodes well for the future?

Well done to all the dev team.


Just to confirm, this means that rather than having to wrap all of the Neon calls in a:

return new Promise((resolve, reject) => { /* ... */ });

call, the Neon functions will natively export promises we can safe.function().then() or await safe.function()?


AFAIK this will be the case. We will wait on the guys though, both are on a day off right now.
[edit: On reading again, I am not sure, I think right now it’s saying only that both will be async, but not 100% interoperable just yet, but as I say we will wait on the guys)


Thanks for another great update! Can’t wait for the birth of baby Fleming! :slight_smile:


probly will get reply from the hating bots but this update doesnt seem clear to non tech guys like me and feels further from any fleming than update 2 weeks ago which cannot be true I know its not most comfortable to give dates but a target like filecoin did in a gantt chart would do. AFAIK fleming can arrive on May or Decemberfor instance but probably the team knows more which of those months are more probable

Most of us were non-tech guys once - especially on such a specialised subject like this ,
Read back through the forum, read the dev forum, rinse and repeat. It will become clearer to you if you have two brain cells to rub together.

Of course if you can’t be arsed putting in the hard work, that’s your problem, not ours.

If you want to be at the front of this exciting new tech, then it takes work. If you just want to make a fast buck of everyone else’s work, then your card is marked, pal.

Love the hating bot. **cheesy grin **


So it is false :wink:


Thank you team, thank you community for keeping it all together and marching on in spite of all the turbulences.


The magic of open source!


What a cool name than Vault 2a test net.


Baby Yoda just got a friend :+1:


Thanks so much to the entire team for all of your hard work!


I am waiting a local single section test net like as a child before X-mas… :laughing:


At least you are confident it will be 2020. That’s positive thinking in action. December is only 10 months away.


I thought the consensus view was that CORS was not necessary and not a good idea to put in safe browser? Genuinely curious.


As I understand it and based on the discussion we had with Josh / Gabriel, you’re both in agreement. By permissive CORS, they just mean disabling it for all requests (or something akin to Access-Control-Allow-Origin: *, whichever method they go with.) The end result is the same:

window.fetch will ignore the request origin when making requests and developers will be able to ignore CORS concerns entirely.