Safe Network Dev Update - March 18, 2021


Here are some of the main things to highlight since the last dev update:

  • We are excited to announce the creation of the BambooGarden Fund which will be used for initiatives to help Network rollout and adoption! Full details on a separate forum post here
  • Lazy messaging flows are coming together in sn_node, with promising results so far, plus simplified code.
  • We’re confident we’ve finally cracked section wallet splits, seeing this in action flawlessly today. This allows us to re-enable relocations, and so reward payouts, moving onto tackling any issues that arise there.
  • Everyone loves a bit of @jimcollinson - check out his new screencast demonstrating how we’re designing things with the aim of making it straightforward to start earning Safe Network Tokens, even for those not confident on computers.
  • @dimitar was a guest on the Bulgarian crypto podcast “Cyber people” which was released this week. If you speak Bulgarian you can watch the full episode here, otherwise you have to check out his “easter egg” at 58 minutes in here :joy: :clap:
  • Keep a regular eye on the Like This Tweet thread on the forum for some excellent guidance on how to help promote the Safe Network, and surrounding components, with a simple button click! :bird:

Announcing the BambooGarden Fund :mega:

We are delighted to announce the creation of a fund to be used for initiatives which will either directly help with the Safe Network rollout, or build a user base for the Safe Network once live.

We have created a separate forum post here with much more detail.

Step 1 towards being able to take applications for funding is to find fund committee members from the community, who can volunteer their time to help set the scope for the first area(s) that should be targeted, and of course to review and vote on applications for funding. If you would like volunteer to join the fund committee then you will find all the details in the fund forum post.

Safe Client, Nodes, Routing and qp2p

Safe Network Transfers Project Plan
Safe Client Project Plan
Safe Network Node Project Plan
Safe Routing Project Plan

Lazy Messaging

We’ve been taking a bigger look at nodes in the last week, with the new lazy messaging flows in mind, and how we can get those implemented. As a result we’ve actually made some large changes to the node code to simplify things somewhat, which allows us to more concretely retain some relation to the message that triggered a given node action, so we can fail with this context, as required.

It’s been a good and rapid refactor there, which seems to have got us to a good point. We’re now integrating the associated messaging changes into sn_routing to properly route and/or error if our messaging is out of sync with the Network. Once we have that, we should be in a good spot to start throwing errors via the lazy messaging pattern when they arise at nodes.

Section wallet split

Dealing with the split of the section wallet was a tough nut to crack when trying to have an old constellation (the parent section Elders) sign the transfer to the new sibling sections.

What we ended up doing was reusing the genesis flow, where the new section Elders simply propose the creation of a new wallet.

Today we got the splits working for several subsequent splits (no end seen there). This means we can now re-enable the relocations and so the proceeding reward payouts, which were disabled during development of the splits.

Reward payouts

We did have successful reward payouts before the code refactor, but currently there’s some fixing to do to get it up again. We’re already delving into that.

Elder size

The PR to increase elder size to 7 has been on hold because it necessitated some changes in the client libs. They have been implemented now and are being tested. Once we verify everything works correctly, we can immediately merge this PR.


We started working on detailed technical documentation for sn_routing. Its aim is to be a single canonical source of information about the inner workings of routing and its various algorithms, so new developers who want to dive into it have easier time doing so. We also want to make it easier to formally prove those algorithms. The documentation is currently being polished and reviewed and will be published soon.


Similar to what we’ve recently done with our FilesContainer abstraction in sn_api, i.e. have all the content stored on Blobs and keeping only the Safe link in the FilesContainer, we are now starting to make the same type of changes to our NRS Container implementation. This won’t be affecting how users interact, create and/or access the NRS names and subnames, but just how the data is stored on the network. Each new version of the mappings created for an NRS name will now be serialised and stored on a public immutable Blob, keeping only a link from the NRS container to each of these Blobs. In this way, the NRS container will still keep track of history of changes while restricting the amount of content stored on the mutable piece of content to simply be Safe links.

As explained in the section below, we are also moving away from the Sequence data type to the new Register data type which is a simpler and more robust CRDT for supporting concurrent operations from different clients, thus the NRS containers will be stored on Registers, rather than Maps as it currently is. With this in place we will have all our data abstraction implementations based on CRDT.


Bounded Counter work has been progressing steadily. We now have the theory in place for paying to allocate op’s ahead of time and ensuring that all op’s will always have the chance to be persisted durably across a supermajority of Elders. What remains is to validate this theory through some PoC code to make sure we’re not missing anything in the details.

MerkleReg: We’ve settled on a traversal API for the MerkleReg, this gives us the ability to walk back through the branching history of a register, as well as query for any newer data that’s been written to the register. rust-crdt #116

With this now in place, we started migrating away from the Sequence data type to the new Register data type. The changes for our sn_data_types crate are ready (PR #352), and we are now working towards adapting the sn_client counterpart, plus sn_messaging accordingly (PR #65).

Safe Network App & UX of Farming

For your weekly dose of UX, check out this quick screencast from @jimcollinson demonstrating how we’re designing things with the aim of making it straightforward to start earning Safe Network Tokens, even for those who are not super confident with computers.

It shows the conversational style onboarding we’re devising for key areas of the app for first time use, aiming to step people through some of the more nuanced flows without being overly verbose.

Useful Links

Feel free to reply below with links to translations of this dev update and moderators will add them here:

:russia: Russian ; :germany: German ; :spain: Spanish ; :france: French ; :bulgaria: Bulgarian

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!


dfdfgkjnasdkj skdjgasfd g

edit: first!



Fantastic news! It’s happening ladies and gentleman!


Great update! Looking forward to hearing more good news.


This is exciting to hear! It could also be a good idea for MaidSafe (as well as those actively building Safe dApps) to post RFPs as well.

Great to hear about all the development progress as well!

Here’s the supporting tweet for you to like, retweet & comment!


Great update again MS. Thanks for all the hard work!!


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



Our forum is the best! We have the best moderators, and the most intelligent and dignified threads and posts. :racehorse:


Also : Roadmap has been updated :slight_smile:


I said a few months ago after what was a hopeful Christmas test net that perhaps it would turn into an Easter :hatching_chick: gift. Did I actually guess correctly for once in this forum? I hope so. Things looking better.


Great update! Really exciting stuff, especially the BambooGarden Fund. If Safe Network can launch with a number of quality apps, it will attract users and their data. If it helps to refine the core too, even better. Many thanks to the kind and generous beneficiary! :clap:

That sounds like a good standard design for combining mutable and immutable data. It should also take the load off elders and allow more immutable data to be easily cached (from the app, through the client and any hops on route too). As discussed in another thread, immutable data is fantastic for caching, as it never changes. This opens the doorway for fully/semi offline apps and a very fast user experience. Great stuff!

Excellent news!

I had a quick poke around at the PR for this. Does this improve the performance when returning the latest value, reducing the amount of traversal required? I didn’t do a deep dive, but it did look like it was the case from first looks. If so, given the latest value is what you usually need, that should help a lot.

So much good news in this update! So chuffed to read of so much coming together! :exploding_head:


No, it just allows to traverse the history of values written to the register from a given entry’s hash. A ref (hash) to latest value is always kept separate and up to date, so there is no traversal required for it.


Thanks what I thought :wink::joy:


We certainly do! Thank you so much!

¡Chinga! ¡Qué vato! ¡Órale!



Wow. Great work again :+1: well done all.

Would I be right in saying “Lazy Messaging” is the last hurdle to testnet - Well last known hurdle as of now :grin::grin:


Dos cervezas por favor!!!


Las cervezas is just for the homies, ese. You gotta show me some pinches tatuajes, wey.


Is this Scottish Gaelic or are you two just drunk? Oh wait, maybe that’s what Scottish Gaelic is!


I spent a couple of months in Mexico two years ago. :slight_smile:

EDIT: I’m writing “gangsta” slang. I don’t think Google translate can handle it.