SAFE Network Dev Update - May 30, 2019


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


Another week has flown by so it must be time for another quick update from the Marketing Team. It’s been a busy week out-and-about for various folks. Today @dirvine’s been discussing the future of the internet to a sold-out Digital Scotland 2019 conference whilst @ustulation and @nbaksalyar presented at the SAFE Network Brighton meetup last Thursday. The guys discussed the upcoming changes in the SAFE Network backend and the interoperability with Solid. There were some particularly insightful questions from the audience about the implications of Perpetual Data and the effects of storing data forever on the Network, and it was a delight to have these conversations with people of such diverse backgrounds. You can follow the Meetup page for news about more upcoming events - and thanks again to Johnathan and team for their work in putting this on.

Here’s a snapshot from the night. We’re reliably informed that @ustulation performed a triple backflip immediately after this was taken - but perhaps you can apply your own caption…

We also put out a new SAFE Buzz interview with @bart at the end of last week - you can check that out here. Next up, a quick word on exchanges. We’re in the process of adding Bittrex International onto the website currently (and of course removing Cryptopia).

Final reminder: @Sotros25 is running the SAFE Network: Chicago meetup tonight in association with the Chicago Blockchain Project (details here). Lastly, @dugcampbell will be heading down to the Web3 stream of the CogX Conference in London in a couple of weeks - so give us a shout if you’re also heading along!


Last week we shared the very first draft of a high level document for a SAFE CLI, which would allow users to deal with all kinds of operations on the SAFE Network. We have also started planning for the development of a first PoC version and have already commenced development over the last few days, you can see our first steps in this public repository:

We also created the current CLI dev plan as a project board in the same repository. As you can see, we are trying to get the $ safe keys and $ safe wallet commands implemented first, which will form the very first PoC release of the CLI. The approach we took, to be able to have our automated tests created before the safe_client_libs APIs are available, is to have a little mock implementation of how we imagine those APIs will be and we base the CLI API and UI development on top of it allowing us to even have our unit tests created.

On the SAFE Browser side, we continue fixing some high priority issues and working on some functional enhancements for our next release. For those interested in more details, you can always look at our SAFE Browser project board, where you will be able to view the issues/tasks we are treating as high priority. At the moment we are focusing on some internal enhancements around tabs managements implementation to solve several issues we’ve been experiencing.

SAFE Client Libs

We are moving full steam ahead with the development of Proof of Concept implementation of 3 recently published RFCs: new data types (AppendOnlyData and unsequenced MutableData), unpublished Immutable Data, and Safecoin.

We are leveraging the existing mock Vault implementation in SAFE Client Libs to quickly iterate on the design: having concrete APIs and simple test apps helps us to hone the RFCs before the final comment period and it will allow us to move quicker with the real implementation of these RFCs in Vaults. We already found some possible points for improvement: GetKey RPC, responses simplification, and Routing simplification.

The new data types and Safecoin affect almost all components of Client Libs, so we keep on estimating and defining the tasks required to be done for this project. You can keep track of the progress on the relevant project boards for new data types and Safecoin.

Because of these changes we’ve also had to do some routine work to update the dependencies, so we released new minor technical versions of Crust, Self-Encryption, and MaidSafe-Utilities.


Continuing the recent flurry of RFCs, we’ve been working on drafting an RFC for a Boneh-Lynn-Shacham (BLS) cryptographic scheme that we anticipate will be used in a number of situations. It will both greatly reduce bandwidth overhead and further protect against replay and rogue key attacks. It’s an exciting component and builds on, among other things, Distributed Key Generation completed by the POA team for HBBFT.

As with previous RFCs we greatly value all the community feedback and it’s fantastic to see all the engagement. In particular, the Safecoin RFC has generated a lot of activity and the discussion is still very much ongoing. We would like to thank @neo, @happybeing, @riddim and @mav to mention only a few, and everyone else for their excellent contributions.

Another community contribution is this pull request by @d1vyank (on GitHub), much appreciated!

The detailed plan for the Routing teams is being extended to cover how BLS will be used in the chain, and how to implement Reliable Message Delivery (RMD) and Secure Message Delivery (SMD). We still aren’t quite ready to share it publically as we focused on covering more topics rather than making the plan more presentable this week; but we will soon be working on presentability and should have something to share in the near future. Also, just a reminder that the two Message Delivery RFCs will remain open for the next 10 days to allow for final comment.

Following the completion of the Safecoin RFC, resources have been reallocated to start working on a Vault Proof of Concept, which is a big step towards handling data in the network.

Node Ageing implementation is progressing nicely with additional PRs in the pipeline and the spec being fleshed out. Work has been done on being more precise about shared state, which includes creating a SharedState type and making sure it’s correctly maintained during churn.

Looking ahead a little, soon we plan to start transitioning the routing crate over to use quic-p2p. This is another item that will further simplify Routing.



Still life in this old timer :bearded_person: yet lol


Tada ‌‌ ‌‌ ‌‌ ‌‌ ‌‌ ‌‌ ‌‌ ‌‌ ‌‌ ‌‌


Thanks for sharing it


Music to my ears. Great work team! Fleming feels like it’s just around the corner…


I’d expect nothing less.


Great seeing Safe Network/Maidsafe front and center (and rightly so) at the Digital Scotland event.

Image source:


That jacket is becoming very famous already! :smile: I can imagine it in a exhibition case in the future SAFE-Cafe! :sunglasses:


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


NIce to hear about the public events!

(Bolding by me) I guess this is referring to this passage by @dirvine earlier this week in here:


I am guessing David sat extra still trying to prevent it from creaking too much this time around :laughing: . Needs to slap a big ole SAFE Network logo on the back of that thing!


Great update as per usual! The Safecoin RFC thread here on the forum has been really interesting to follow. Safecoin could well end up being one of the most interesting coins in the entire crypto-space … I’d bet a few yocto-safe’s on that easy … lol … maybe even some nano-safe’s … I’m not a big gambler in the end I guess, but ya get the idea maybe?

This looks to be really cool … reducing bandwidth overheads is always a big win.

Just when you think things can’t get much better they somehow do … more proof we are living in a simulation!? lol

Thanks for the update!


Coding POCs. At work on vaults. Getting the word out. A lot to like in this update.


Nice one!


A post was merged into an existing topic: Protocol://Domain.Subdomain/Path

I just noticed that the RFC’s for Fleming are either getting on in time or received very few community comments, some have had no comments for nearly a week. I assume the team are plowing on regardless of whatever the end dates for the RFC’s are?

RFC 54 and 55 can in no way be realised for Fleming, IMO. So that there might be a reason. I hope the work with the (amazing) new data types does not begin before we have a full network MVP running, that would be wasted energy IMO - an unnecessary delay to that immensely important first MVP.

RFC 56 and 58 I personally didn’t find much to comment on actually. It didn’t seem to contain much controversy or questions (I might be wrong there of course).

RFC 57 though, that is both essential for MVP and riddled with questions and controversy. So it reflects in the topic length as well :slight_smile: