SAFE Network Dev Update - March 28, 2019


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


Following the developer feedback received on DevHub, we’ve started to implement some of the changes that we hope will improve the user experience. Today we added a new DApps page, which showcases some example applications developed for the SAFE Network, including the exciting, new community apps from @happybeing, @oetyng, @nigel and @glen_simister. We’d see this page getting regular updates as new DApps are developed, and to this end there’s a new Dev Forum topic where developers can submit their projects for inclusion. We’d be happy to get any feedback, or notification of amazing in-development apps from our community developers, so please don’t be shy!

And @oetyng has popped up once again! This time, he’s been good enough to answer a few questions about his SAFE project in an interview (check out Part 1 and Part 2). Finally, some of you might have noticed a tweetstorm we put out earlier today. We’re planning to do a regular roundup of stories of interest to SAFE followers but looking for inspiration for a name! So if anyone has any thoughts, please just add them to the thread below.


A couple of pieces of housekeeping to update you with this week. A month or so ago, @douglas.santos joined the Crust team but he’s now taken the decision to move in favour of working on an in-person, rather than remote, role. He leaves with our best wishes - as does @povilasb who alas we’re sad to report is also moving on. We’ve known for a while that Povilas planned to move to New Zealand and unfortunately managing the different timezones in such a collaborative project as Crust is not ideal. So we’d like to thank him for all his hard work over the past few years as he goes to work on a few personal projects - he’ll be sorely missed and we look forward to seeing him continuing to pop up in the community as we move forwards. And who knows what the future may hold!

Inevitably, from experience, we understand that some people question why people choose to leave. So for the record, it’s worth reiterating that both reasons are unrelated - and it’s crucial to note that we are actively recruiting to fill the gap! You may have seen our tweets - so this is where you can all help! Please do share/intro/point us towards anyone that could be a great fit in building the next Internet as we look to fill that gap!


We made available a new version (v0.11.0) of @maidsafe/safe-node-app. For details of the changes and additions included in this new release, please refer to the CHANGELOG. Apart from all the technical changes included in this release, it’s worth highlighting the enhancements made to the documentation available in the README file. Among other things, it now explains in much more detail how this package is structured so new developers can better understand it, how to contribute to the project, and gives a high-level overview of the API.

As we’ve been mentioning in the last few dev updates, within the front-end team, we were researching and working on a first command line user interface since we understand that GUI may not be ideal in all circumstances for users and developers. We believe there are certain use cases where having CLI tools can provide additional benefits and support more types of applications (and/or types of users) than only having GUIs.

This is why we started by exploring the possibility of having a SAFE Authenticator CLI, which interacts directly with our SAFE Client Libs with Rust, and we are very excited to share it with all of you today. Note this small project is in its nascency, and we are trying to get the community engaged in its progress at this early stage. We have created a new thread with more details about how to use the CLI, and also to use it for all discussions and support related to it:

In browser land, we’ve had a pleasant week. First off, we got a new browser version release (v0.12.0).

Beyond that, we’ve been stabilising our CI E2E tests. We’ve dropped Spectron (which is based on Selenium), for a new, vastly more reliable test runner called TestCafe. For the browser UI tests, TestCafe has proven to be actually reliable. This is a big step up from our previous, brittle Spectron tests. We’ve also made a good whack at standardising our code base, reducing linter bugs considerably. And we’ve got a potential solution for reintroducing Windows builds (now with Travis), which is also working well with the new TestCafe setup. This involves tweaking how we manage the native lib dependencies in safe_app_nodejs and the browser (in order to avoid some obscure Windows issues which have broken the CI recently).

We are glad to announce that v0.1.1 of the SAFE Messages app was released this week as an updated PoC. See this post for more information. You can download the latest APK from this GitHub release. Have a look at the changelog for the list of changes.

SAFE Client Libs

We’re glad to announce that this week @lionel.faber joins our team to work as a full time Rust developer. He’s been doing exceptional as a member of the Mobile Dev team and we’re looking forward to his contributions to SAFE Client Libs!

This week saw continued work on the documentation, with us adding a Core data types page to the wiki and an About section to the Readme. We made a number of edits to the Introduction and Contributing pages trying to make them more accessible, based on feedback from @davidpbrown. We are also improving the FFI code documentation as well as fixing a few FFI bugs that we noticed while writing up the FFI pages. In addition, we want to thank @mav and @southside for their recent Pull Requests to the project – your contributions are highly appreciated!

Work on the RDF front has been slowed down a wee bit during the last week due to @nbaksalyar joining the Crust team to help with the current projects. However, we’re staying on top of things and considering many of the valuable comments we’ve received both from our community and team members. The work on RDF proof-of-concept will also reignite soon with Lionel joining the team.


The Routing team is continuing its march towards Fleming.

On the Parsec side, we decided last week to leave out a number of tasks for after Fleming was real. We now moved all of these to a “Parsec-milestone-3” milestone in Jira so that it is easier to track the remaining progress of Parsec needed for Fleming (Parsec-milestone-2).
Of the tasks that do need to be tackled for Fleming, we tackled a good chunk this week.
We added tests for a couple of new malice detections: InvalidSelfParent and InvalidOtherParent.
We recently changed the way gossip communications are represented in the gossip graph by adding a Requesting sync event. This allows creating a structure that can easily and cheaply be inspected for correctness. This week, we used this new structure to detect malicious gossip patterns more easily than we would originally have.
A bug in the detection of interesting events was also fixed, and another bug in the way seeing is defined in the presence of forks.

We are satisfied that our PARSEC v2.0 (properly asynchronous with a common coin) paper is as ready as we’ll get it, and we have submitted it for review to the Journal of Parallel and Distributed Computing. This process may be lengthy (12 weeks average time from submission to first decision. 45 weeks from submission to acceptance), but we hope it will help us make the paper as tight as possible through academic review, and gain some academic recognition for the algorithm. We will keep you up-to-date as the review process progresses.

On Fleming, we are getting closer to implementation by firming up our understanding of node ageing. We actually started some refactoring work in Routing and are progressing the implementation specifications for other Routing changes needed for Fleming.

We are all looking forward to being able to dive into the Routing code and making the magic happen :slight_smile:


This week we implemented two binaries to help us test the QUIC based Crust implementation. We use bootstrap_node and client_node to spawn multiple Crust nodes, connect them together and exchange some data. With those tools in hand, we started aggressively testing our implementation. As is expected when testing some bugs have been found in quinn itself, which we’re helping to fix, and the quinn folks are very helpful and effective at solving those issues.

We keep pushing quinn to its limits and in the meantime we also considered an alternative QUIC implementation in Rust: quiche. quiche turned out to be less ergonomic to use. It is sans I/O implementation and we would need to implement the I/O layer ourselves which quinn already has, hence quiche was not considered any further.

To be clear, the QUIC spec since becoming managed by the IETF really is a very attractive protocol for secured P2P networks. This is a large departure from the original server focus. The reason we are spending time here is that QUIC is basically what Crust was intended to be. Of course, we have our own parts, such as random ports, restarts, bootstrap cache, etc. but fundamentally the underlying protocol is close to perfect for us. In addition, it means SAFE engineers no longer need to be network protocol designers and that itself is a huge boost for us. The hope here is that with QUIC we can align with new Internet standards and simply use the protocol that now meets our requirements of security and accessibility. Very exciting to work with this protocol and see just how the rest of the Internet is seeing things as we did so long ago. In essence, this test, if successful, means we can focus on SAFE and less so on any network protocols.


Wow!!! Second!!! Early update!!


Goodbye and best wishes to @povilasb. We didn’t get to work much together but I enjoyed meeting you at FOSDEM :slight_smile: Have fun in NZ!

Edit: Farewell to @douglas.santos also :cry:


Impressive update! Lots going on and I’m excited about the new CLI auth client - very much needed!

Also great to hear PARSEC v2 is progressing well and QUIC is delivering.

Sorry to hear @povilasb is leaving though. I hope NZ works out though - I hear it is a beautiful place to live!

Would it be possible to link the JIRA project when mentioned? It would be an easy way to see Fleming progress.


Cheers to @povilasb you’ve been a great asset and always a joy reading your forum posts. Wishing you the best and hope to see you return someday!

QUIC will save a lot of resources for @maidsafe. The knowledge learned in Crust up to this point and what has been achieved are still highly valuable. @ustulation probably knows Crust better than anyone I imagine. Will it still need to do hole punching? What will be unique to Crust after QUIC is implemented?

Thanks for putting JAMS in the dApps on DevHub and was glad that @Nick_Virag, whom is also at the helm of JAMS, was able to provide valuable feedback for the DevHub, etc. Nick is accomplishing some really cool things and we’re always plugging away. Any reason we don’t see Project Decorum, Decorum Wallet App, and SAFE Wallet? Or SAFE-FS? The more the merrier and all still running projects AFAIK. We’re doing our personal best to get back on the Alpha 2 Network.

Hope that the PARSEC paper gets excellent and helpful acedemic feedback and acknowledgment.
Congrats on the release of the CLI too!
Cheers to everyone!


This process may be lengthy (12 weeks average time from submission to first decision. 45 weeks from submission to acceptance)

Does this mean that you will not share the Parsec v2.0 whitepaper until up to possible almost a year?.. that doesnt sound good.


Decent question. I’m curious if PARSEC will be published under open access once it’s initially accepted. There are open access publications on the site.


Thank you for the hard work and SN T-shirt at FOSDEM @povilasb and good luck in New Zealand!


Thanks so much for all of your hard work!

“We’re planning to do a regular roundup of stories of interest to SAFE followers but looking for inspiration for a name!”

What about just calling it SAFEnews? Or maybe SAFE-Reddit? Or maybe SAFE-RSS? How about SAFE-Roundup?


Not just great when it’s published, but I guess a very big milestone for @maidsafe to have this thing to work from. Quite amazing :+1::+1::+1:


They actually don’t need to wait for acceptance to publish it on an arxiv preprint repository. It’s a widely accepted practice now. For this topic, > would be appropriate I believe. @maidsafe please consider this strategy but of course make sure it aligns with your desired outcome


From @oetyng’s interview:

I immerse myself so fully and totally into what I do. As long as it’s something I have a motivation to do, I’ll eventually be very good at it.

Yes this comes across in your forum posts and demos (and your code too no doubt). Nice thing is there’s confidence with no hint of arrogance, and the bit of backstory you provide kind of explains that too.


The safedev website is slick.
Nice professional look.

Anyone who hasn’t taken a look, do it…

I did find this broken link though.

clicking that link…


Exciting updates! Thank you for keeping the community up on the progress.


I don’t know a lot of the practices about publishing scientific papers, but when you mentioned I had to think about that strange Russian mathematician Perelman who published the important proof for the Poincare Conjecture on It helped of course that Perelman had already a good reputation, so his proof was taken seriously. But also 3 years between publishing and official confirmation of the proof.


@maidsafe, great update as usual

Sad to see these good, much loved, people leave but such is life in a long term project and life continues as you recruit others. I hope @povilasb and @douglas.santos enjoy and find fulfilment in their new positions.

Just curious as to why it should be a problem for the peer review to take that long. Its not like it will delay the project at all.


It’s the future of scientific publication. Every key paper is also submitted to a preprint now even if the authors are going through traditional submission. Traditional publishers were forced to make special allowances for preprint submission in bio fields while in machine learning preprint is really the only way now (with community review).
It also makes the review process more inclusive so that even if biased reviewers reject the manuscript in the traditional route (editor + 3 peer reviewers), the rest of the scientific community can have a say.
The other important considerations are speed (your discovery won’t be stuck in lengthy review while a competing group can scoop you months later because they had more amenable reviewers/editor) and open access.


I hadn’t gotten to part 2 of @oetyng’s interview until just now. From someone who has bohemian ancestry to someone who lived like one, it’s a real pleasure to know that we had a very similar experience in being attracted to this project. Seeing bitcoin’s abilities and then limitations, and then ethereum’s abilities and limitations, and then finding the ‘SAFE project’, the way it was described made all the pieces fall into place and the picture so clear. Even before things like disjoint sections were engineered, the general end goal idea was there, it made logical sense, it just needed designing and building. Beyond that the discussions on this forum always engaging and knowledgeable, truly the last pleasant place on the clear net. What gives me hope is that these are the folks we’re getting a fresh start with. All that rambling said, I simply can’t wait to see what it is you have up your sleeve Ed!


Great update Maidsafe devs,

Goodluck @povilasb in nz/personal projects and thanks for all your hard work, see you on the forum. Goodluck @douglas.santos with your new role and see you on the forum :sweat_smile:

Wow just wow, this time around the SAFE Message app worked lightning fast (it was just a great ux), also fun the see the app’s own container details in the SAFE auth.

@mav and @southside :+1::+1::+1:


You can install and run software from it too. I ran SAFEBrowser v.0.11.1 from it!

:exploding_head: :vulcan_salute:



Nice to see things happening. Always keeping an eye as per usual.