SAFE Network Dev Update - September 26, 2019


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

  • We released a new version of the SAFE Browser, bringing some really nice features of the pWeb (the Perpetual Web).
  • As part of the Vaults Phase 2 work, we are starting to make the necessary changes to make sure the Vaults have the same view of the data states for all supported network operations.
  • In the SAFE CLI repo, a lot of work has been carried out on getting the first set of FFI (Foreign Function Interface) functions for the SAFE APIs ready and functional. The PR which includes the setup to generate the native libs, C# bindings, and covers most of the APIs has been reviewed and merged.
  • Work on implementing Node Ageing has started.


This is the last dev update of September :fallen_leaf: - how exciting! And as usual, we’ve got a ton of news for you this week. First up in marketing is the fortnightly newsletter which should have dropped into your inbox this afternoon (UK time). We discuss the rise of cashless societies, what has contributed to such a move and where crypto fits in all this. We’ll publish this on Medium soon as well so you don’t miss out - but why not make sure you are subscribed to the newsletter and you’ll get the stories straight to your inbox?!

We’ve also got a surveillance-themed tweetstorm this week so head over to Twitter to check it out. If we’ve missed any pressing stories this week then make sure you let us know by popping them in the forum or tag us on Twitter.

Vaults Phase 2

Project plan

We are continuing to progress through the Phase 2 projects, mainly focusing on two lines of work: mock Routing and restating the Vault operations in terms of achieving consensus.

We covered the mock Routing in last week’s update, but it’s only a part of the story. In Phase 1 Vaults, most request handlers are implemented naively: because we don’t need to have consensus in the context of a single Vault, the flow of operations takes some shortcuts that won’t work with multiple Vaults. Now, we are making the necessary changes to make sure the Vaults have the same view of the data states for all supported network operations. This is a well-understood problem and we’re already past the design stage. The approach we’re taking requires a small number of changes in the Routing API and in the Vault code. Changes are beginning to flow in with PR#852 which lays in the basic structure for handling consensus and PR#854 where deletion, transfer coins and LoginPacket requests are made to go through the consensus algorithm.

With PR#1034 good to get merged, AppPermissions are all set to be optimized and revamped (explained here in the SCL section) in the mock vault inside the SAFE Client Libs. Corresponding changes are underway in the real vaults to adapt them to the new way of handling application permissions.

Within the Routing crate, we got PRs merged tackling when a PARSEC graph pruning should be carried out. The further work of carrying out detailed pruning work is progressed as well.

While we have your attention, it is worth mentioning that the shared Vault (as part of Vaults Phase 1) was restarted earlier this week and so the vault_connection_info.config file has been updated in the GitHub releases for the vault. See the latest Vault release for the new vault_connection_info.config file - if you intend to use the shared vault you should download this to the relevant location for your platform :wink:


Project plan

As you all know, so far we’ve created the first set of SAFE API bindings for NodeJS. This means that web apps and the SAFE Browser itself can use the same APIs that are used by the SAFE CLI. But over the last couple of weeks (and especially during the last few days), a lot of work has been carried out on getting the first set of FFI (Foreign Function Interface) functions for the SAFE APIs ready and functional. This now allows us to start work on creating the SAFE API bindings for C# language (and eventually for Java and other languages). This means the APIs will also be usable by the mobile browser.

We’ve also built some automated tests for the NodeJS bindings (with Jest), which ensure that the data is stored and retrieved correctly when using each of the SAFE APIs. Since all the functionality and logic of the APIs is found at the Rust layer and many scenarios are tested at that level, the tests on the NodeJS binding, as well as in any other bindings, become simpler. They simply make sure that data is correctly transformed back and forth through the binding layer.

We are now considering a bit of refactoring and restructuring in the repo, since we now have three crates to manage: 1) the safe-api exposing the Rust SAFE API, 2) the safe-cli containing the SAFE CLI app source code and depending on safe-api, and 3) the safe-api-ffi which is the layer containing all the FFI functions totally isolated/decoupled from the rest, and obviously depending on safe-api. Therefore we’ll keep working on this over the next few days to finalise some reorganisation we’ve already done.

Lastly, in parallel we continued with trying to fix some minor issues and adding a new feature which is to allow selecting a specific spendable balance from a Wallet for any of the supported operations. So far all wallet commands would use the default spendable balance as the source/target for any operation made on Wallets. Now we’re trying to allow users to give the friendly name of the spendable balance in the URL so the command can act on it instead of the default spendable balance. E.g., if we have a spendable balance with name to-pay-beers on a Wallet which URL is safe://mywallet, we would now be able to check its balance with:

$ safe wallet balance safe://mywallet/to-pay-beers

SAFE Desktop Browser

Project plan

Today we release a new version of the SAFE Browser! We’re introducing some really nice features of the pWeb (the Perpetual Web), allowing users to not only view SAFE sites and their older versions but also to register NRS names (the SAFE Name Resolution System) right from the browser. Users can also now upload and edit their sites (from within the browser).

At this point in time, we haven’t put much effort in the UI/styling of these features. We’re just making them available with basic functionality so you can taste the future of the Internet already right here, right now!

So go ahead and download it from our GitHub releases page, and start playing around with these nice new features. Remember you’ll need to have the safe_auth CLI running and logged in to either the shared vault or a local vault you may be running.

Just to give you an idea of the things you’ll be able to do with this new version, here are some high-level descriptions:

  • Fetch websites using NRS-URLs and XOR-URLs, browsing back and forth in their version history seeing the websites in each of their versions
  • If you try to fetch a website using an NRS name which hasn’t yet been registered, you will be offered the chance to create and register that NRS name with your account! For those who know how current Internet DNS registration works this is interesting to experience :wink:
  • If you are visiting a website you own, you can edit it right there in the Browser by selecting a local folder (only a folder can be selected in this version) where you want to upload the new website files from. The browser will take care of uploading it and republishing it in your NRS name and URL.
  • Websites can alternatively be uploaded and published on an NRS name using the SAFE CLI. Once that’s published they can be fetched either with the CLI or with the SAFE Browser (although note it’s not possible yet to edit a website using the Browser which was uploaded with the CLI, neither the other way around, a limitation we will be working on soon in relation to supporting sharing permissions among apps).

If you create a site on the shared vault then why not share the NRS or XOR URL in the thread for others to see!

Just a reminder for those who haven’t been testing our last releases, please keep in mind this is not compatible or usable with the Alpha 2 test network, but only for the new shared and local vaults as explained in this post.

SAFE Mobile Browser

Project plan

This week we finished the automated UI testing setup for the SAFE mobile browser. To validate the test setup, we added UI tests for some scenarios to test bottom navigation buttons, toggling app theme, opening FAQ page, etc. These tests show that automated UI testing is feasible and is easy to implement. However, work on the mobile browser has been paused for now due to ongoing work in safe_app_csharp which is our prime focus right now.


Project plan

This week we continued to expose more bindings for the new APIs and covered lots of use cases. The PR which includes the setup to generate the native libs, C# bindings, and covers most of the APIs has been reviewed and merged. We still have to refactor and improve the code to make it production-ready.

Once finished, the bindings will help us to provide the simple and clean API for C# and many other languages.

In parallel, we added new issues into our GitHub repo for all the new APIs which we are going to work on next. This will help the team to track the work progress. Also, we have already started to consume the bindings to provide the C# API for mobile and desktop development.

Node Ageing

Project plan

Some have already spotted this, but we have started implementing Node Ageing :tada:

We have chosen to kick this off with a small focused team right now (think Delta Force, just tougher :wink: ). This work involves the introduction of the Adult and Infant personas as well as solidifying the Elder status. It reduces the bootstrap and join process to a much simpler mechanism and allows us to remove candidate and resource proving.

We’ve scoped the initial tasks into the board, and will expand further onto other tasks as we move into a deeper implementation phase.

Node ageing allows us to begin to realise the significance of Sybil resistance proper and make use of those benefits, particularly as now we have PARSEC in play. BLS is happening in parallel and will help tremendously.

In short, this is a big push by the backend team and they are showing great skill and commitment to this aggressive timescale and workload.


Project plan

As we’ve redirected some staff to kick off node ageing, BLS will slow down ever so slightly, but the implementation for DKG (Distributed Key Generation) continues to progress and we merged the work using PARSEC to collect signature shares for the SectionInfo.

As the node ageing bootstrap/join piece of work completes, BLS will be able to resume at full speed.

Useful Links

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


First… :smiley::smiley::smiley::smiley:


The second one!!!
We are top!!!


Thanks so much to all of the team for all of your hard work. The progress is accelerating!


The pWeb… give 'em the P.

We knew you wanted the P… so we P’d in your web.

The Safe Network… a new Web, with all the P you could ever want.

looking for a new Web? come join us, we’ll give you the P.



Why was the Windows version of the browser delayed?
Here I am all ready to get it and it’s not there yet.
Seems kind of strange not to release them all at once.


Node ageing!


Quick comments while I read:

  • I think it should point out this is the first SAFE Browser that doesn’t support alpha 2!
  • the link to the config from the release page doesn’t link to the config but the vault. Can we have a direct link to the config?

After creating a new account dWeb Blog is back on Fleming at safe://dweb (also on alpha 2 and at

Another great step forward: SAFE Browser with support for the Perpetual Web!

Another week of great work from the team - thank you all very much.


It’s just that we didn’t fully finished automating its packaging yet, so we do it manually still, plus testing it was a bit delayed due to several things we were tackling, but it’ll be ready soon :slight_smile:


Vamos pelado!! To the moon!


Oh, that is awesome! Fast and intuitive!


Great update and good to see solid progress on many fronts!


Thanks again for the exciting update!

I spotted some “bugs” in the text. Please proofread once more before publishing on Medium. E.g.:
“Make you don’t miss out!” -> “Make sure you don’t miss out!”

EDIT: A bit sorry to be “that guy”.


Exactly ! :grinning::muscle::rocket:


This just turned too R. Kelly for my liking :laughing: .

Regardless, keep trucking MaidSafe!




But these are quibbles, another beautiful update! Despite the occasional typo, these updates still set the standard in the crypto space for thoroughness, integrity, and transparency—it’s appreciated.


Gr-update day!

Cool idea! Perhaps other things (settings/network-info) can be implemented this way.

Hoorah! A big move forward - things are coming together fast!

They do indeed! I’ve followed quite a few projects and this is certainly the most open one that I’ve seen.

EDIT: looking at the roadmap, it seems we are just a couple of ticks away from Fleming now! :wink: Just Secure Message Delivery and Node Aging - both of which are underway.


I think only BLS and Node Ageing remain for Flemming, but I could be wrong. Vaults 2 shouldn’t be too far away. I can’t wait


Is BLS part of Secure Message Delivery? I don’t recall.


I wouldn’t have a clue but it is separated out on the project plan. SMD has some further improvements to occur as we travel closer to launch

1 Like

Think of BLS as section (group) signatures. We use quorums of ed signatures right now and have emulated multisig really. BLS allows these section signatures to be aggregate signatures (cryptographically more secure). That affects a lot really in routing, but secure message delivery is one area. Right now we emulate BLS in routing as a step towards actual BLS DKG (Distributed Key Generation). That last parts of that work is to swap the emulator with real BLS.