SAFE Network Dev Update - February 21, 2019


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

  • Continuing the series of posts started three weeks ago, the Routing team released this post to highlight the main questions their current brainstorming sessions are centered around.
  • @douglas.santos has joined the team this week to work alongside @povilasb in the Crust team.


As mentioned last week, the Marketing team has been focused almost exclusively on continuing its deep dive into Fleming Tech. Meanwhile, @dirvine was interviewed on Mozilla’s IRL Podcast and @nicklambert was quoted in an article on the Verdict website.


Following our long search, we are delighted to announce that we have found another Network Engineer, to work alongside @povilasb in the Crust team. Please join us in welcoming @douglas.santos to the team!


We are currently at the end of the third development sprint for the UI/UX enhancement milestone for the SAFE Authenticator mobile application. Issues reported by QA from the second sprint are being resolved this week. @vigneshwara is riding solo for the safe_app_java milestone, which will include exploring the new features available in JUnit 5 to improve the test suite. The team is also looking into the pain points around app authentication and the IPC mechanism currently followed across platforms. We will be investigating alternative approaches to improve the authentication experience.

This week the first release candidate of the SAFE Browser was made available and is currently in our usual internal testing phase. Based on the findings during this phase, we will be able to share the new release (v0.11.2) fairly soon. As usual, we’ll be preparing the changelog for sharing it with you when ready.

In tandem with this, we’ve made the first tentative steps towards adopting TypeScript. With the relatively new ability to use TypeScript with Babel (a JavaScript preprocessor) it’s been a surprisingly painless process preparing the browser codebase for TypeScript. So once we have the last kinks worked out with the CI we’re hopeful to get this merged and be in a good place to start implementing types and type checking in the browser codebase in the near future!

There has been a lot of internal discussions and brainstorming sessions trying to agree on our next steps for the Browser, Authenticator, and other components of the front-end team in general. As part of these sessions we were also trying to share knowledge across different teams to be able to make decisions which consider several perspectives, e.g. what’s required in the long run for the authentication process when thinking not just about desktop applications or web apps but also mobile apps, and how to move forward in the direction of making the process easy and clear for the end user.

SAFE Client Libs

This week we came up with a definite plan for making our extensive Client Libs documentation public. We’ve chosen to use a GitHub wiki on the repository to host all the docs in one place, which we can link to from the Readme, source code, and the Dev Hub (with summaries). We have collated all of our docs into a private list and have marked the ones which require review versus those that are still WIP. We plan to review and publish about three new pages per week. This week we will be publishing our “Introductory Concepts” pages, starting with “Building Client Libs”. Next week will be about more technical core concepts as we feel that this is the most important information to publicise first.

Next week we will also move some of the content of the Client Libs Readme to the wiki, and add links from the Readme to the relevant wiki pages. This should make the Readme easier to navigate, containing only the most important information, while letting more inquisitive users know where they can find more details. The Readme will be updated sometime next week.

In the meantime, Yogeshwar finished a first major milestone in the transition of SAFE Bindgen to the new parsing framework syn, which supports the latest additions to the Rust syntax, so eventually we can finally switch all of our repositories to use the latest stable version of Rust. This work is being reviewed now and should be merged upstream soon. See the safe_bindgen project boards for more details.


This week the Fleming sub-team have again been concentrating on producing more detailed figures relating to the Network’s resistance to Sybil attacks, and in discussing more of the “big picture” issues surrounding the Fleming release. These discussions have included topics such as hot restart of nodes (nodes being allowed to restart in order to upgrade their binary without suffering a normal relocation penalty), network restart, network upgrades and message delivery through the network (especially in a situation where a less than ideal connectivity could be expected).

Continuing the series of posts started three weeks ago, we released this post to highlight the main questions our current brainstorming sessions are centered around.

There was further effort put into bringing the Parsec whitepaper in line with the current idea of using a distributed key generation algorithm in order to make Parsec fully asynchronous. This work is still proceeding well, and in fact it has revealed an implementation bug in our current implementation of the concrete coin calculation.

The other sub-team have been pressing on with resolving issues and seeking performance improvements in the current Parsec codebase. We have identified a couple of new issues related to malice-handling which are being addressed at the moment, and the benchmark suite has again been improved to make it more relevant to our expected usage of Parsec by Routing.


The Crust team is very happy with the latest reinforcement - @douglas.santos. We’ve started the onboarding process and soon enough we will see some contributions from Douglas as well :slight_smile:

The QA team has started aggressively testing the Crust bootstrap cache implementation and these guys are not joking - already found a few bugs! The fixes are on the way.

We had a lot of discussions about the very next piece of work in Crust which should aid Fleming release goals. We decided that dynamic connection management is the highest priority at this moment and started defining more specific tasks on GitHub.


first for the second time!


welcome to the safe family @douglas.santos =)


oh seems to be still very far away this fleming


I’m far too surprised that @douglas.santos has a dot in his name! All hail the bringer of new ideas :bowing_man:


Welcome aboard @douglas.santos!

Thanks once again to everybody for all their hardwork!


Gogo maidsafe!!! You guys are awesome


Awesome! Keep it going maidsafe. We’re all behind you.


Keep up the good work! And welcome to Douglas Santos!


GogoRustrust maidsafe!!!


Welcome aboard @douglas.santos! You’re stepping in at an exciting time :wink:


A good update, lot’s of stuff going on. I believe I read in the past that the team works off Confluence. Why didn’t you just create a publicly available/viewable space on your Confluence instance and serve the documentation that way? With something like the Viewport plugin, you could make a really nice looking documentation space instead of a file dump into github.


Awesome! I can’t think I’ll ever write without it if I have too. Might be because I come from an embedded background…

What exactly is Babel used for here? I thought Babel’s main purpose was to make sure code runs on platforms that don’t support certain newer versions, but I don’t see where that would be an issue with the modern SAFE Browser?


It is a transpiler so will transpile the typescript to javascript AFAIK.


TypeScript compiles to plain JavaScript by definition. I have used Babel to transpile from one ECMA version to another, and to support stuff like Promises and other classes, but not for much else.


Let’s face it, no one has any idea so don’t sweat it and enjoy the ride (if you can)


We use babel to be able to happily code es7/next/what have you. So it’s transpiling that safely to es5. (this way we dont have to keep track of what’s valid in a given chromium version [and we’re still on chromium 61 w/ electron 2.x, so we don’t have allll the latest snazzy features]). But essentially babel means we don’t have to worry about the browser support for specific language features (even if we’re in the happy position of only having one browser to support).

And now it’s also handling typescript code (which, as I understand, is effectively stripping it out for the JS builds, so it can build without a compile time hit). So we can have all this nicely working with webpack dev servers etc. (This means we’ll be running type checking as an additional test on the codebase, as opposed to using typescript for compilation of the JS itself).


Hey @wydileie :slight_smile: You are correct, we do use Confluence internally and we did consider whether to make these pages available as is. However we think something like github could be better as it allows community contributions easier.

There are other tools we are using which we are experimenting with also. So in the spirit of continuous improvement, these may come into use in the future, or perhaps for another team.

Regardless, we will however aim to make the readability and usability of these docs top priority.


Cool! See there are some benefits to combining TypeScript with Babel now. Though the benefits you mention can be had with TypeScript on its own as far as I can see, except it’s probably easier for your codebases to transition into TypeScript nicely.

Glad to see TypeScript being used. Hopefully makes my half hand-made declaration file unnecessary soon!


Hi there, @riddim! Thank you, very much. I’m happy to be part of the team. :smiley: