Safe Network Dev Update - November 12, 2020


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

  • Some big updates to the Safe Network Lexicon are ready to be unveiled! Watch the video here or read the transcript in the dedicated forum thread here.
  • Work is underway to support multiple clients using the same public key to connect concurrently and mutate data.
  • Further network startup performance improvements have been merged to sn_routing.

Updating the Safe Network Lexicon

We’re updating the Safe Network lexicon for end users, and replacing the terms Account, Safecoin, and Vault.

This will probably feel like a biggy, so @jimcollinson has made a video setting out all the details on why we need to do this, and what we are proposing to replace them with.

Please feel free to add your thoughts, and comments, and observations in the dedicated thread on the subject, where you’ll also find a full transcript of the video.

Safe Client, Nodes and qp2p

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

With the section startup changes merging into sn_routing last week, it brought in a few breaking changes to sn_node where newly joining infant nodes undergo relocation back to the same section immediately to induce ageing. This relocation has to be worked around or ignored in sn_node as it takes a relocating node to be someone from a different section and so proceeds to fetch the wallet IDs, rewards, stats, etc. from the previous section, not realising that it is an infant undergoing induced ageing. We are well underway with a refactor to take this scenario into consideration, alongside a few more fixes for blob data flow that re-enables chunk replication at adult nodes.

A parallel task we have just started on is to support having several clients which make use of the same public key when connecting concurrently from different devices/instances to mutate data. For example, a user may have a public key which owns his/her emails, and he/she uses an email application from a mobile and laptop at the same time. Currently there is a limitation for this use case, and we are trying to now support it by allowing the application to provide some form of application instance identifier. Such an identifier would be used internally in the CRDT operations to make sure both instances of the app can mutate data concurrently without creating data merge conflicts.


The initial Sequence CRDT proptests have been merged into sn_data_types, which increase confidence and coverage. Part of this test setup led to us improving permission handling to avoid potential branching issues when old permission ops were applied, now also merged to master.

This work has also shone a light on the need for CRDT operations to be signed to be able to verify the entity that initiated the operation. This gives us more confidence, but also shifts permission checks into the data itself, which should make testing this much simpler. As such, we’ve started work on getting the sequence ops signed, with the aim of verifying validity of ops against permitted public keys.

We’ve also got a POC draft of a Map CRDT type compiling with some basic proptests passing there. There are still changes to be made w/r/t the internals of the Map, but this has the same style of permissions as the Sequence type, which means once we have augmented that with sigs and verification for ops, we should be able to port it over to Map easily enough.

DSB Dynamic Membership

Our CRDT consultant has been plugging away. This week he has implemented an example node that communicates using QP2P and supports both peer join and removal (kill). A particular issue has been identified regarding how to deal with messages initiated before a voting membership change. The Generation Clock is thought to be a solution here, but that still needs to be proven out with tests.

In parallel, the original bft-crdts crate is being broken apart into smaller, more focused library crates. The idea is to loosely couple (a) the particular secure broadcast implementation, (b) the data being secured, and (c) the network transport (e.g. QUIC, TCP/IP, or in-memory network for simulated tests).


Project Plan

As proposed in last week’s update, the work to further improve the startup phase has now been merged. This improves the startup performance by giving new infant nodes a wider pseudo-randomly generated age range and only relocating the oldest nodes, therefore avoiding too many nodes being relocated at the same time.

In progress at the moment is work to allow a node to rejoin with the same name. This is designed based on the Subsequently Joining the Network section of the Node Ageing RFC. The intention is that a node trying to rejoin with the same name will be immediately relocated with age halved, as long as the halved age is greater than the MIN_AGE (currently 4).

There is also ongoing work to improve lost peer detection, with the support of qp2p. The basic plan here is to ping peers on connection loss to confirm if they really have gone offline. With lots of aspects needing to be considered and balanced, particularly as this is such a key factor of faulty peer detection, there are ongoing internal discussions and debate to find the best way forward.

Useful Links

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

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


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



Very interested to watch this.

All in all, it seems like there’s a lot of “final cleanup” going on—all hopefully indicating an imminent testnet/release. Looks like things are coming together at a good time and pace. :blush:


Are the UI images in that youtube video all mock ups. Or is there any actual app built already?

Also has any decision on MaidSafeCoin to Safe Network Token, conversion process been had?


Why is the min age 4? why not 0?


Thx for your continuous hard work Maidsafe devs.

Always nice to see a @JimCollinson vid, love the changes

Keep up the good work super ants


Just wow @JimCollinson, totally love the way you made a video. Clean, totally quiet room, laptop with a safety sticker on a camera, 2 guitars on the wall, lamp and totally cool and focused Jim - nothing more.

After this piece, you really proved you are the guy we all need. All the changes you announced in this video are great tweaks, it’s very well thought out, everything makes sense.

Keep pushing this way, it’s great! More videos like this, please!

In video there was announced:

No more accounts, users will operate under their safes. Great idea IMO!

Safecoin no more -> it will be “Safe Network Token”

Btw. regarding ticker, I very like the idea of the letter X at the beginning of the ticker meaning stateless. As you probably know, in currencies the first letter defines the country. But gold is stateless, therefore XAU, silver is stateless, therefore XAG. As far as I know, cryptocurrencies like XRP, XMR, XLM, XTZ are having there X for the same reason. I can imagine the Safe Network Token under XSN.

Also, Jim just announced they will try to avoid using vault in a frontend, preferring rather verb “Earn”. As you explained it, I completely agree and I believe the community will like it too.

Once again thank you!


Great update and as @Sotros25 says there is a feeling that lots of little details are getting cleaned up as prep for a significant announcement/launch.

Exciting times.

Now to watch @JimCollinson 's video and learn the new terms.

Off-topic - the price on Bittrex shows a healthy positive trend. I have withdrawn some sell orders.

EDIT: Forgot to add my thanks to ALL who have taken us to this stage - past and present staff.


This seems taken by a project called Stakenet. But I like this ‘X’ idea. What about


NT = Network Token

Because in the future it will be the only network that matters :slight_smile:


I might be wrong, but it sounds like we are close to some sort of launch :rocket:


Really good quality video.
More please. :slight_smile:


A glancing view perhaps is one way to sense check and it’s good…

Safe and Safe Network Tokens make a lot of simple sense - both are immediate and obvious, which is ideal… and is a good play into the common notions of making something safe.
Earn - fine, seems a good idea to encourage thought about being active.

I wonder missing is a name for the endpoint… but node will do for all instance perhaps.

If ever there was use for types of ant for the names of worker elements, I think I’d like that too!..


We don’t call it launch anymore… it’s the becomoning :smiley: or the start… the awakening!


Relocation is when you see 2^age churn events. So start at 4 == 16 events. Just gives us time to monitor.


Great work and loving the new lexicon! I can’t wait to see it all in action!


Thank you for another week of great progress!

I wonder why the network startup is such a hassle? Couldn’t you just start it from an “artificially prepared frozen state”, where there is a working section from the get go? Why does it need to form from zero, by itself? The startup is supposed to be done only once after all, isn’t it? After that there will always be some kind of history to lean on to, right?

I’m quite sure there are good reasons, I would just like to understand a bit of them :thinking:


Absolutely excellent vocabulary evolution. I’m shocked I/we didn’t think of that type of safe as an avatar before. It’s too perfect.

I love the way this is all starting to feel as it reaches maturity.

Incredible work, team.


Really excellent video, @JimCollinson - thank you for such a clear and helpful explainer!

:ant: :ant: :ant:


Hey good job guys
btw, I hope that the “Safe Network Token” was trademarked before this announcement…

(PS: I wonder if “Safe Network Tokens” is just a placeholder for a future name… as it doesn’t roll off the tongue and it is too generic. Imagine a casual conversation about accepting the “tokens”, and the potential of being used as a means of exchange outside of the safe network. Eventually I guess it may end up shortened as Safe Tokens by the users… but wouldn’t it be nice if we had a concise memorable name so it is clearly identifiable? It sounds like the parody character in Rick and Morty to which they didn’t bother to give a proper name like “Bird Person”, making him too literally descriptive and generic.)


This is a good point, the symbols beginning with X would be a great idea to future-proof it in case it goes mainstream as a means of exchange (becoming money). Making it compatible with ISO 4217 from the get go would be really smart, as many other projects did… but
Although it is too early to tell, probably the ISO 4217 will either be amended or they’ll release a new standard in the future to accommodate the flood of cryptocurrencies as it will exceed the total possible number of combinations with two characters. (technically it has already exceeded, but not all of them opted to use the X scheme)
Until then, all these X names are as informal as any other token, but at least for now the tokens that start with an X are clearly communicating the desire of being taken seriously as currencies in the traditional financial system.