SAFE Network Dev Update - August 2, 2018

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

  • David, Viv, Gabriel, Nick and Francis have been representing MaidSafe and speaking about the SAFE Network at the Decentralized Web Summit in San Francisco.
  • We’ve refreshed the MaidSafe website on a temporary basis.
  • There has been some press activity with our latest Medium post and an article in
  • Having applied for mozfest 2018 we’re looking forward to hearing back from the organizers - see the registration status here.
  • Josh has written a summary of the WebIDs and RDF data and we’ve got detailed posts on the new APIs and how RDF data is being stored on the network.
  • The team has been looking to improve our project management for safe_app_java and set up milestones for safe_app_csharp and safe_mobile.
  • DevHub will soon see more developer guides for desktop and mobile apps.
  • There’s been more work on the PARSEC FFI with tests having been written, the API defined and implementation started.
  • The Crust Team are redesigning SAFE Crypto to make it more flexible and reliable for all other libraries to access.


As some of you may have already noticed we have revised This is a temporary site to bring the site more in-line with the new site and reduce the duplication of information across platforms. The current design style will act as a stop gap but we feel it more accurately represents the vision of the company and our continual push towards SAFE Network branding. As previously mentioned this division between MaidSafe as a company and the SAFE Network as the platform is an important distinction as although we are currently the primary developers bringing the Network to fruition we hope that in the future we will not be. This is a community project and we want to create that distinction. The SAFE Network is for the people by the people!

Decentralized Web Summit

This week much of the focus has been in sunny San Francisco as David, Viv, Nick, Gabriel and Francis have been spreading the SAFE word at the Decentralized Web Summit. Following a successful networking event on Tuesday (see pictures below with Tim Berners Lee) the team presented in the San Francisco Mint and to audiences around the world via the livestream on the SAFE Network and our recently work with SOLID. You can watch it all back now. Once the team returns to sunny (unlikely) Scotland we will share their findings, news and plans but until then here are a few pictures from the Summit so far.



In response to our presence at the Decentralized Web Summit there has been some great press activity. First off read our latest Medium post as we focus on the Global Visions theme of the Decentralized Web Summit. David has also been featured in’s recent series from the Summit.


As some of you will be glad to hear, we applied for mozfest 2018 that will take place Oct 26-28 in London. Anyone can follow the registration process on github where we expect to hear from the organizers at some point in September.
What would be the title of our presentation, you ask?

Taking back the web! Set up your first SAFE website in under a minute


As promised, we’ve a couple of posts detailing on the new APIs and how RDF data is being stored on the network. And for those who don’t want to go to deep, @joshuef has written up an overview on medium too.

As well as this (while some of the team are at the Summit), we’ve been adding in some smaller tweaks to the POC apps and the Peruse WebId release, repairing CI tests after the recent merge-splurge, and setting up PRs for updated versions of the client libs. Which we’ll be rolling in to updated versions of safe_app_nodejs and Peruse once that’s all tested and verified.

As the team is busy fixing the JNI errors we’ve been facing, we have been polishing up our project management process for safe_app_java. This is to provide better visibility to the community with regard to roadmaps and development progress.

This week we setup new milestones for safe_app_csharp and safe_mobile. Now community can track work progress for both projects using boards and milestones in official GitHub repositories. API documentation for safe_app_csharp is in review in this pull request. We have started to work on developer’s guide for .Net developers which help them while developing desktop and mobile apps for SAFE Network using .NET Core, .Net Framework and Xamarin. These guides will be published soon on SAFE Network DevHub website.

SAFE Client Libs

This week we’ve continued work on the PARSEC FFI, having written the tests and defined the API. Writing the tests first has helped us to design an API that we think will be simple and easy to use. We have begun the code review process for this portion; in the meantime, we’ve already started implementing the API, a task which is proceeding quickly. Note that some details of the API might change based on code review or other factors.

We’ve been also involved in helping the front-end team with finding a cause of a critical known bug that is observed by some community members. The bug occasionally shows up in the Peruse browser that uses the latest version of SAFE Client Libs. We’ve been debugging deeply inside the Client Libs code and came to the conclusion that this error originates on the front-end side because of the garbage collection that happens prematurely. The front-end team will now be investigating it to figure out the root cause and apply a fix.


Following up from last week, the routing team has continued brainstorming all aspects of dynamic membership in PARSEC. We have now crystallized our understanding of the different ways malicious peers can be detected and punished. With this understanding, we also know exactly how to safely handle adding and removing peers, a.k.a: dynamic membership. This work is of crucial importance as it relates to the security fundamentals of PARSEC which itself is the bedrock of the routing layer of the network.
In these discussions, we have also covered the separation of responsibilities between routing and PARSEC. Even though routing integration will only be the subject of the next milestone, it is important that we define the boundaries now so we know what exactly must be handled by PARSEC at the present time. This will also allow us to turn the PARSEC crate into a fully self-contained consensus mechanism that anyone can reuse for their own permission-less network use-cases.

We also made good progress on the property testing front, with Rust’s Proptest library. The tests gained the capability for automatic simplification of the randomly generated schedules. To explain this in more detail, we have to describe the simulation model a bit first.

The virtual network for testing PARSEC is simulated in the following way:

  • First, a list of peers and a list of transactions the peers will vote for are generated.

  • Next, a schedule is generated. The schedule consists of steps, and during every such step:

    • A node can perform a local step, which consists of receiving incoming messages and optional sending of some messages
    • A node can fail and stop responding forever
    • A node can vote for a transaction

    All of the above things happen with some probability.

  • Every sent message has a recipient and a delay. Delays are also generated randomly, with some given distribution. They are the numbers of global steps that have to pass before the recipient will be able to receive the message during its local step.

  • There are some more options: votes can get duplicated, failures can be planned deterministically instead of randomly, etc.

So, the schedule is basically a list of events, each of which is one of the three possibilities listed above (local step, failure, vote).

When we run a test with Proptest, we define some range of parameters we want to test. The parameters include the number of peers, transactions, the probabilities of nodes taking a local step / failing / voting, and all the other options. What Proptest does, it starts somewhere within this range, then “complicates” the case if there is no failure, or “simplifies” it if there is a failure. This way it attempts to find the simplest set of parameters that exhibits a failure.

We defined a set of rules that say what cases are simpler, and what cases are more complex. For example, the less peers in the network, the simpler the case. The higher the probability of a node taking a local step, the simpler the case (it’s closer to a synchronous setting), etc.

Given a schedule generated for some given set of parameters, we can sometimes simplify it directly. For example, if we reduce the number of peers, we can take out all the events that concern a subset of peers. Say, we throw peer A out, and then: if peer A was scheduled to take a local step, this event gets removed; if it was supposed to fail, the event gets removed, etc. This way we can increase the probability that a modified schedule will still exhibit the same failure, or no failure at all.

Unfortunately, we currently can do this only with the number of peers and the number of transactions. If, for example, the probability of a peer taking a local step changes, we have no easy way of modifying the schedule - we have to start from scratch and generate it again with the new parameters. We are still looking into ways of improving this situation, but it doesn’t seem to be straightforward.

We have been contacted by Antonio Sabado from who would be interested in having some of us present the SAFE Network and PARSEC in a deep dive presentation in King’s College, London some time in September or October. We are still working out the details, but it seems that @bart and @pierrechevalier83 will be able to attend that event together and spread the word around our core technologies to that deeply technical audience :smile:. Expect to hear more from us on this in the near future :wink:


A lot of our libraries heavily rely on SAFE Crypto which recently we discovered is not flexible enough. So we decided to redo it, hence Crust and Routing will be affected. But better sooner than later :slight_smile: The new SAFE Crypto design is work in progress and when everybody approves the changes, we’ll have to redo the Crust integration into Routing. No worries though, it seems like it’s gonna be lots of robotic changes rather than a complex task.

We also did some improvements on our automated tests. First, there was one netsim based test failing in Crust. Which is now fixed and all Crust tests are passing. Then we have peer inactivity tests that check what happens when remote peer becomes irresponsive. The usual peer timeout is about 2 minutes, but we don’t want to wait that long during testing - we have multiple test cases :slight_smile: So we made peer inactivity timeout configurable which can be set per test basis.


First !!! I watched the presentation with great interest! Thank you for the efforts David, Viv, Nick, Gabriel and Francis! Great job :slight_smile:


looks like I’m first :smiley:


EDIT darn…


This week has been amazing. I remember saying awhile back when things were quiet that it was the calm before the storm. I think just now the storm is rolling in, I can hear the thunderous clapping of progress building, and not too far off a torrential downpour of excitement and interest will be imminent.

A lot to digest here. Great work at the summit, at home base, Chennai, and everywhere else @maidsafe. SAFE travels to those who were on the move and be proud! You did great :slight_smile:


ssfecoin down 12% today dunno what is the reason…

The neverending wait? This update was not even ready to yet talk about when next alpha is released, not to mention beta or final.


Not sure why, but I cannot access the updated maidsafe website at all - getting a “Safari can’t find the server” message.

Taking time to branch PARSEC out as an independent crate for other people… how egalitarian!
…Maybe don’t bother :smiling_imp:. J/k, tho there still looks to be a bit of a plate of different areas to solve.

1 Like

Hi @David_MacGregor - I’m at home on the chez_gedd wifi and I’m okay… Is it still down?

I did have an issue this morning for 20 seconds or so but on refresh it was grand.

Starting to worry a wee bit now.


1 Like

Great news. Price seems on the dip :grin:

Hi @DGeddes - I’m attempting to access it from New Zealand. I just tried again using a different browser and got this message:’s server IP address could not be found

1 Like

now that is twisting my melon man… I shall have to seek assistance aven mon colleagues.

Nice Update great work everyone :+1:

PS @DGeddes in Oz and the sites been accessible on multiple browsers this morning.


Do you have a VPN @David_MacGregor? If so what happens if you route through a different country?

1 Like

No, I let my previous VPN service lapse due to lack of use - but I’m assuming VPN would work if connected to countries where it is already working. It may be just NZ that is an issue,

I’m now getting the same dns error.

Mobiles still fine.

1 Like

I don’t have NZ on mine, unfortunately but I tried Hong Kong and Ukraine, which work, and Singapore, which doesn’t. What does this mean? ¯_(ツ)_/¯

1 Like

Might be a DNS propagation issue. If the domain was redirected to a new server recently, the change might not have reached some places.

See DNS Checker - DNS Check Propagation Tool


Yes, I think you’re right - especially if a new server is involved.


Sounds great! Also enjoying all the RDF info.