SAFE Network Dev Update - October 17, 2019


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

  • @jimcollinson made a video where he talks about the thought process, user research, and testing that has gone into the on-boarding design for the Network.
  • We released a new version of the SAFE CLI (v0.5.0).
  • We started publishing the safe-api (SAFE Rust API) on


Just a wee update from the team this week. We’ve published our regular tweetstorm over on Twitter so go check it out and let us know what you think - it was quite a week in the world of surveillance, privacy and internet shenanigans so an interesting one to curate. We’ve also published the content from the SAFE Gossip newsletter a few weeks back, looking at the rise of cashless societies. You know the drill - head over and clap 50 times please!

But before we go, we’d like to bring to your attention the amazing work by the community’s Bulgarian superstar @Dimitar. His website, which is of course all about SAFE, has been nominated for an award and you can find out all the details here. Things like this are truly humbling and it’s incredible to see how committed this community is every single day.

Vaults Phase 2

Project plan

This week we have been focussing on working out the details of the Routing interface which is to be used by Vaults. It is straightforward for cases when a Vault calls the Routing library (e.g. when requesting a consensus vote), but we need to be more prudent in cases when Routing needs to pass events & data down to Vaults because we don’t want to expose the Routing internals too much, so as to minimise the knowledge required to use the library. In the end, it is more of a software design challenge: we want to have a minimal and understandable API while still maintaining the ability to test Routing and the network in various configurations (with or without real networking, with mock PARSEC, and so on). We have found some good solutions to these problems and we are getting close to integrating the real Routing with Vaults. The progress can be tracked in the issue #878.

In parallel, we are continuing to work on the consensus voting for client requests. With just a couple of exceptions, all the client requests now go via consensus. This makes the Vault ready to interface with the Routing library, so very exciting times ahead. We’re also working at overcoming some of the limitations in the Phase 1 vault, for example the vault currently does not handle refunds when some data operations fail. With the enhancements in this PR, the vault can identify legitimate errors returned by data handlers and refund the Client that paid for the operation.

SAFE CLI (Command Line Interface)

Project plan

SAFE CLI v0.5.0 has been released and made available for everyone to upgrade with $ safe update, or it can be downloaded from the GitHub releases page if you didn’t have a previous version of it.

In this new SAFE CLI version, a couple of new features we’ve talked about in previous dev updates were included, e.g. the ability to choose a specific spendable balance from a Wallet for any command, and the new dog command to inspect URLs and their resolution, among other minor enhancements and bug fixes (refer to the changelog for more details).

We also started publishing the safe-api (SAFE Rust API) on Yesterday, safe-api v0.5.0 was published, and although we still have to work on the safe-api documentation, it’s already available for Rust applications to use it as a dependency from there.

This allowed us to publish a new version (v0.3.1) of the safe-nodejs package, which is now depending on the latest safe-api v0.5.0 from This new version now includes all the Node.js bindings for the SafeKeys and Wallet APIs which were missing in the previous version, and therefore are now ready to be used by Node.js applications.

Our efforts on creating the Authenticator daemon (authd) continued during this last week, with some successful first tests of starting/stopping the daemon, and interacting with its exposed services (through QUIC), all using the new commands in the SAFE CLI. A new authd client API is what we are working on to allow not just the SAFE CLI but any other applications to be able to communicate with the daemon with no need to understand the communication protocol. We therefore already started trying to get some basic Node.js bindings for this new API, towards trying to test it from Electron applications, which will be required to allow the SAFE Network App to communicate with authd.

SAFE Network App

Another video for you all this week, as @jimcollinson takes you through the thought process, user research, and testing that has gone into the on-boarding design for the Network.

How do you create an account without permission from anyone else, and how is it possible without a centralised process, server, or organisation? And how do you do this while maintaining the security and integrity of the Network, and maintaining personal privacy?

We identified numerous approaches as to how this could work, and how you could get started on the network:

  1. By starting a vault. This is a way of offering resources to the network, and being rewarded with some currency, that you can then use to create an account.
  2. By paying for an account with fiat currency, via an exchange.
  3. Through creating an ‘offline’ account packet, and having a friend who is already on the network, upload it, at a cost to them.
  4. Making an empty offline wallet, sending it to a friend for them to fill up with the required amount, in order for you to create an account from it.
  5. Creating an offline ‘inactive account’ which would then be activated by a user with some Safecoin.
  6. Having another user gift you an invite… a special link which they’d purchase, which would contain all you’d require to get going.
  7. And then, of course not forgetting, there are those of you who already hold MaidSafeCoins, and who will be able to covert some of them to pay for a SAFE Account.

In the video above, Jim talks through how we narrowed these down, and the solutions we’re building first.

We’ve also been continuing on two other fronts:

Updates Project plan
Auth Project plan

On the one hand with the Update project board, as well as other wee tweaks (e.g. using S3 instead of GitHub for downloading resources, as GitHub was proving to be slooooow), and some other internal tweaks to how we manage detecting app version updates.

We’ve also been firing in with experimental auth API integration into the SAFE Network App. Here we can really see the benefit of the new API structure which was born out of safe-cli, with start/stop of the auth daemon, login, logout and create account all getting integrated quickly into the SAFE Network App. We’ll now be smoothing out the rough edges of this implementation, increasing test coverage and, as the APIs stabilise and make it into the safe-api master branch, working towards a release there.

SAFE Desktop Browser

Project plan

We have a new patch release of the browser to be released soon (pending some final QA). This fixes some pWeb resolution issues, as well as adding in another pWeb (Perpetual Web) requirement of blocking un-versioned resources requested by the DOM from another domain. This means you will not be able to pull CSS from safe://somewhere-else and avoid having to version the website when you change layout/content shown, etc.

It’s important to note, this doesn’t prevent folk from using the DOM APIs to request data, it’s just that the original document/content will be reliably versioned and therefore replicable.

We’ve also bundled some dependency updates and a new version of safe-nodejs into the browser. We’ll be exposing the XorUrlEncoder functionality from the API as some folk have been requesting this.


Project plan

This week we added the inspect API from safe-api which allows the devs to get the metadata for any data stored on the network using its safe:// URL. We also added some tests to ensure this API is returning the correct data from the network.

To keep up with the new API and FFI changes, we have updated the Cake build script to use the latest native library generated from the safe-ffi CI. The script can be used to auto-download the native libs based on a release or a master branch’s commit hash.

We have bumped the minimum supported platform versions in safe_app_csharp. This will help us to use the latest C# language features and provide a more stable API.

In parallel, we are testing the APIs with the local vaults for all supported platforms. During testing, we discovered that the new APIs aren’t able to connect to the local/shared vaults from mobile devices. Currently, we are working on a fix to resolve this issue.

Node Ageing

Project plan

As you will see we have whittled Node Age down and have 2 smallish tasks left to do there. That allows us to be more focussed on the vault / routing interface and @ustulation & @nbaksalyar have been busy in parallel (with help from @Jean-Philippe) finalising the implementation design there and in fact implementing that, along with addressing some test failures, and progressing detecting unresponsive nodes.

As node age closes, it means we have Sybil resistance in place. This allows nodes from home (no more centralisation), but we will still maintain the phase 2a/b, 3 and 4 stages of the project plan. We don’t want project pipeline confusion, but we do want serious reduction in time to launch. So a lot happening in parallel here in the backend of vaults while the UX of vaults is being progressed by @lionel.faber, @yogesh & @marcin for phase 2a vaults.

This may seem fast and a bit wild, but this is Engineering at its very best. We are pulling it all together here and leaving time to focus on internals (such as replacing emulated BLS with real BLS) while we try out small testnets (possibly all private to begin with) and confirm acceptability.

We have simplified much of the code here and still have a small amount to do, but the end result is simpler (less bugs), more efficient and importantly a much more understandable code-base. We hope this progress allows us all to enjoy running SAFE in the wild sooner than most realise. We will iterate full networks, not individual components and this is a much more effective approach to roll out.

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 …yay…now to read :smile:

‘>>insert (vaguely) inspirational quote about the early bird<<

Definitely loving the thoughtful and dedicated approach to designing SAFE Network UX/UI!! I don’t know of any other project in the space that’s focusing so clearly on UXD :smile:

Also very excited to see all the great progress on Vaults, the SAFE Browser, Node Aging, and so much more! Tons of great work from the MaidSafe Team!! Full speed ahead :blush:


Wow! 10th [to like] is not bad for me!


The early bird has to hope the worm is not poisonous, not even vaguely :wink:


Third …!


This rocks. The pace continues and even seems to be accelerating. Thank you team.

Amazing work @Dimitar :clap: and apologies for 6-0 in the week. :grimacing:

P.S. Browser update now!!!

EDIT: Props again to @JimCollinson and team for another great video - both content and presentation are very good. I wasn’t clear this was a new video from the update because it looked similar to the last one. Its great both to hear both about the process and effort going into this, where it is taking the design, and hear about why that is. The level of transparency and engagement is fantastic, and I think is also beneficial for the project. Well done all.


Good job! :muscle:
Love the marketing update! The video by @JimCollinson and the website by @Dimitar
Congrats @Dimitar you deserve it!!:partying_face:


Where in github? … …


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


“Vaults from Home (Data)” is listed under “SAFE Maxwell (scope yet to be confirmed)”. Is that what you meant, @Antifragile?


YIkes! that’s one for me.
I’ve updated the roadmap, and missed out the GH version. My bad. I have a bunch of reasons why I’ve been distracted, but ultimately I missed it. I’ll sort that out tomorrow.
Sorry for the confusion.
And thanks for pointing it out.

Edit: Updated :+1:


You’re doing a great job Nadz - don’t stress over it.


Aw! Mwah :kissing_heart: @DGeddes
I like to do my best.


We all hope so too.
Thanks for another great update.


Loving this! Start basic, prove the technology, reassure stake holders, then iterate towards perfection. We are in safe hands here folks (excuse the pun)!

I’m starting to get excited now! :sweat_smile:


Nice to watch your video @JimCollinson
It looks quite easy to get access to The SafeNetwork.

Keep going well.


Wow, again such an amazing update @maidsafe!:tada:

Really excited about this! Rust + SAFE = :heart_eyes:

Also, thanks @JimCollinson for this really interesting video. The user-onboarding-by-invite concept made my jaw drop! :open_mouth:
It is just so inspiring to see, how much thought you guys put into every detail of your product.
In the end, UX will be such a crucial factor for widespread adoption!

Keep rockin’ it @maidsafe! :muscle:


@Dimitar - You the Man. Great effort. It is so exciting watching the project unfold at such a rapid pace. Can’t wait for another month to pass by. Lots of hugs to the whole team


Really enjoyed watching the Jim Collinson video and shared it with my own Telegram group.

This type of presentation certainly helps people understand more about how things will work and increases credibility as to the nature of the project.


can’t wait to see true decentralization! I mean I know a lot of things have come together under the hood but achieving decentralization is where I would say you can now drive this car (even if some parts are still unfinished)