SAFE Network Dev Update - April 18, 2019


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


First up this week, the biggest news is the MaidSafeCoin listing this morning on the Bitker Exchange. The exchange, based in Singapore, now has MAID/BTC, MAID/ETH and MAID/USDT pairs available and we’re delighted the community now has further options when it comes to exchanges that are available. Bitker have confirmed they charge 0% on deposits into the exchange and charge 0.1% commission on all trades with a small charge on any coins withdrawn (currently 3 MAID per withdrawal but we’d advise you to confirm this yourself).

We also released a new SAFE Buzz video. Slightly different set-up on this one as this week we’ve crossed continents and spoken to @lionel.faber, one of our developers based in our Chennai office in India. Hope you enjoy this one - you’ll find out how Lionel came to join the team and get the low-down on his exciting new role.

Next, we’re looking to crowdsource some inspiration from the community! Hopefully you’ve seen this week’s edition of our regular Wednesday tweetstorm covering a few of the key stories each week that we think might be interesting and relevant to the folk that choose to follow the MaidSafe Twitter account. However, we’re still working out what to call it (and need a short, relevant hashtag as well) - so please do let us know if you have any inspiration on this front!


As we get ready for the next release of the SAFE Browser, we’re also in the midst of a push to upgrade electron from v2 to v4. These changes should make subsequent major version upgrades easier, with the goal of keeping up with Chromium releases. The next crucial step we’ve been working on in parallel is replacing webview with BrowserView, as recommended by the Chromium team for increased stability and security.

A new feature was recently added to the safe_auth CLI, this time to allow the use of either a config file, or environment variables (SAFE_AUTH_SECRET and SAFE_AUTH_PASSWORD), to read the SAFE account credentials from, so the user doesn’t need to type them in each time the CLI is executed. This should also allow the safe_auth CLI to be easily integrated with other tools or applications.

Another feature being finalised for safe_auth CLI (which is currently in review) is to prompt the user every time an authorisation request is received, either allow or deny, just like the popup shown to the user by Authenticator in the SAFE Browser. This will happen for all incoming authorisation requests received both as part of the command line argument or as a GET request from the webservice. However, an argument could also be provided to have the safe_auth CLI automatically allow them all without querying the user, which again is analogous to the functionality provided by the SAFE Browser Authenticator when its padlock is unlocked.

SAFE Client Libs

This week we’ve been continuing the work on the front of Rust API improvements for SAFE Client Libs. We’ve merged a pull request from @lionel.faber that introduced non-breaking changes to the Authenticator API, adding Rust functions to manage and revoke user’s apps.

We’ve also merged another pull request with further improvements to the Rust API: adding a new run method which allows interacting with the network in a simpler way. It encapsulates a common idiom found in Rust programs: blocking on an asynchronous operation and sending a result through an MPSC channel. It should make writing simple apps in Rust more straightforward. We intend to continue with these changes, making our APIs more approachable and better documented.

Another small change is the move to a stable Rust in SAFE Client Libs. Now it doesn’t fail with the latest compiler versions, and this change also paves the way for moving to the latest Rust edition (2018). We plan on updating SAFE Client Libs to latest changes in the language and soon we’ll release a new version with all the latest changes.

In other news, @marcin is taking a one month holiday, but with the new team members we expect to continue with full steam ahead.


The work in PARSEC has been winding down this week. We improved the performance of the code when malice detection is enabled, we also have a PR up that will add tests for the recently introduced Requesting/Request/Response pattern.

With these final issues being addressed, PARSEC is reaching the point where we are ready to call it good for Fleming, so the PARSEC and Fleming subteams have been merging back into a single Routing team over the past week, which means that our efforts are now focussed on bringing Routing up to speed.

On one side, we are preparing for the Node Ageing implementation. Work is ongoing in documenting and modelling the flows we are planning to have once Node Ageing is implemented. In order not to couple these models with Routing itself too tightly, we extracted a separate crate for this purpose. A rendered version of the current design of the flow is available here.

On the other side of preparations for Node Ageing, we decided to leverage the state machine we have in Routing to make the code cleaner. This state machine reflects the role of a node in the Network at various stages in its lifetime. Every node begins in the Bootstrapping state. If it’s intended to be a Client, it then transitions into the Client state. If it should be a full Routing node, it transitions to JoiningNode, and then into Node. This last state was so far a catch-all for everything that happens after a node contacts a particular section: the resource proof, the initial relocation, all of it happened with the node being in state Node. The current effort aims to refactor that state into multiple ones, and a PR is already up for the first one of such new states.

In adition to the work on Node Ageing, the Routing team are also working on a new Message Relay scheme. The attempt to replace the Ack-timeout model with N/3-to-N/3 model (described in a recent Dev Update) uncovered multiple issues related to nodes not being in sync. The previous model was masking these problems with timeouts - if some nodes were lagging and failed to pass the message, they had time to catch up before the sender would try again. This isn’t happening in the new model and we are looking for ways to fix it.

Last but not least, we would like to give a shout out to @oetyng for his huge contribution to the issue of naming in Routing! He took the time to share some very thoughtful and excellent feedback on naming inconsistencies in our routing code: Well worth a read for anyone interested in good software engineering practices. We are not forgetting about it - you can be sure that we will take action on this as soon as we can allocate the time :slight_smile:


We have been continuing to stabilise the networking library that uses the QUIC protocol, which has been renamed to quic-p2p now. We’re working on improving the API and want to increase the test coverage to confirm it works as expected in different conditions and scenarios, including the malicious behaviour of clients. Also the bootstrapping functionality remained so we are completing that as well.

At this point we should also keep in mind the quick response time inclusive of bug fixes by the quinn team without which it could have taken us much longer to get to the kind of stability we have just now. They will soon be publishing all the work done (together with bug fixes) to as version 0.3.0


First for first time! time to read…

  1. Is node aging and message relay the last big things needed to be done for routing before testnets?
  2. Any idea how long the Node aging coding should take? days weeks months ?

Great to hear of the Routing progress!

Has there been any more thought about malice detection for if whole sections go bad? Maybe that won’t be a concern for Fleming, but it would be nice to know if it seems theoretically feasible.


I happened to catch me asking myself pretty much the same questions :face_with_monocle: :hugs:

Would be nice to know what is left to be done before being able to participate in a Fleming test :thinking:

(not wanting to increase the pressure - but to me it’s not obvious what would be blocking now anymore…?)


Thanks to all of the team for all of the hard work!


Thanks for the update! Reminds me about one of my first questions here! :slightly_smiling_face:

Nice to see this integrated!


I called it Supercalifragilisticexpialidocious! Ever onward in this grand, great, glorious, splendid, superb, and wonderful network! Great job :+1:


what to call what lol? a title for a tweetstorm of news articles? a title for tweetstorming in general? An account name for tweetstorms?

I liked the NoServers hashtag! I think it’s good because it speaks to relevant issues people that might never have heard of the SAFE network have ideas about. It can be hard to get your own hashtag to gain traction though. I would suggest try to be part of other hashtags that already got some traction and have relevance to what we are doing here. some examples could be: Decentralize, DataServices, FreeTheNet, MyDatMyLife or ControlYourData


Was great getting to know @lionel.faber and his positivity is simply contagious. I couldn’t help but smile watching the interview :smile: as always the magnificent @Cgray really knows how to gently guide through the weekly buzz. I personally quite like the SAFE Buzz and I hope others come to enjoy them as they become aware of the project.

Great news on the new exchange! It really would be great to see some increased trading as price speculation/increase is a huge motivator for people in this space, drives people to the project, to join the community, and spread the good word :wink:

Wooot!!! Probably a nice sigh of relief and feeling of accomplishment on this milestone.

Great work once again @oetyng it’s nice seeing so much activity coming from within the community and also such bright minds joining the forum recently.


Great to see the CLI tools being powered up !
How do you implement a notification requiring intervention on a terminal only machine if the user is “somewhere else” ? Something like wall ? Or does it only happen inside the terminal where the safe_auth resides ?

1 Like

There’s a couple of things here - hashtags that would help to get in front of the right audience on Twitter are one side of it. But also just what we call “The [ X ] Tweetstorm” that we send out every week when we refer to it! We can talk about “the weekly summary of news stories that we send out” but it doesn’t sound too catchy. It’s not a big thing by any means, we’ve got some thoughts - but always like crowdsourcing these things from the community where we have the opportunity! The shorter the better though in both cases given the fact that it’s Twitter.


IMO the best Twitter storms tell a story, like a blog post broken down into its constituent parts. So maybe concentrate on a certain type of news story each week. Week 1 could be privacy, week 2 censorship, week 3 security (easy that one as breaches are a daily occurrence), week 4 developments in the regulatory landscape, week 5 decentralisation, … [repeat]. That would allow us to focus on patterns emerging in particular areas rather than trying to cover the whole privacy-security-freedom picture in a broad-brush way.


@dirvine are you not involved in the routing implementation ? as it seems you also do wounder about the node aging and message relay progres?

Not so much the impl, but proof of concept and design overview, but the routing team are a bunch of talented self motivated Engineers. So I do try and keep away to let them at the details etc.


Do you have any idea when the next alpha public test network will be released? Before this summer would be possible?

It’s just around the corner. Ever seen a Daytona track

1 Like

around the corner of a not yet built track you mean?

Great update Maidsafe devs,

Happy holidays @marcin :sunglasses:

@oetyng :clap::clap::clap:

Please keep the dev vids coming, :clap:SAFEbuzz



oh ok. maybe the weekly data watch? Or maybe the weekly data owl? Too hairy potter? Hmmm I’ll spend some time thinking on this and report back when I got something golden.