Last week, we released the fourth dev tutorial (Markdown editor).
Now we are focussing on getting the required changes for SAFE Authenticator in place. Earlier today, we moved the 3 RFCs related to the new authentication flow + granular permission control from proposed to active (because we are now starting to work on implementing them). The 3 RFCs are still up for debate and changes will be accepted if they are agreed upon. Our proof of concepts tests are almost done and we’ve started specifying the required tasks and breaking them down into several subtasks.
In parallel, the Routing team is making good progress on the Disjoints Group implementation. Most of the tests in routing are now passing (we’re down to 3 failing tests). Once the tests in safe_vault pass, too, we will move to in-house network tests with actual vault binaries and start implementing the Node Ageing RFC (which we need to implement in order to produce vault binaries that users can run from home).
SAFE Authenticator
We have done some proof of concepts for the SAFE Authenticator plugin (for SAFE Browser) and now we are actually starting the work on the plugin. One of the proof of concepts was to test URL scheme registration on multiple platforms (OS X, Linux, Windows).
SAFE Core
We have started the implementation of MutableData (and the new paradigm of Authenticator-based interaction) in routing + safe_core.
MutableData provides fine-grained access control and more narrow-scoped data operations. This data type is an evolved version of AppendableData. It combines StructuredData and AppendableData features and improves the network efficiency, saves bandwidth, and provides a standardised approach for apps to fetch and mutate data in the network.
Routing & Vault
We finally got the routing churn test to pass consistently with disjoint groups: It simulates a network with joining and leaving nodes, and after each change verifies that the new network invariant is satisfied, i.e. every node has made a connection to every node that it needs in its routing table according to RFC 37, and in particular that the routing tables of all members of a group are identical (except for the implementation detail that a node doesn’t put itself in its routing table). When a group is big enough it now splits up into two and notifies its neighbouring groups, and if a group loses a node and drops below the minimum size, it merges with at least one other group and also notifies all connected groups, to allow them to update their routing tables. The passing churn test confirms that we have now covered all the edge cases and have all the message flows in place for the network to adapt its structure.
We’re down to 3 failing tests out of 102, and those all point to a particular problem with groups failing to send a message while they’re in the process of merging. We’re already working on the fix for that.
After sorting those out, we will move on to testing a routing example application on droplets, while some of us will iron out any remaining test failures in safe_vault. When those tests pass, too, we will test vault binaries on droplets again, and start implementing the Node Ageing RFC.
We are also gathering ideas for improving and unifying some of the synchronisation mechanisms that we have implemented separately and not always in the same fashion in routing and safe_vault, and that would benefit from a better theoretical foundation and a clear, agreed upon order for handling events. In particular, we are discussing adapting the Tangaroa or Chandr-Toueg consensus algorithms for our use cases.
And finally, we have extended the routing simulation to take into account good (non-attacker) nodes joining and leaving, for computing estimates of an attacker’s chances with different parameters (group size, quorum, etc.). With Node Ageing, short-lived good nodes are an advantage for the attacker, as there will be less old and trusted nodes to compete with, so the parameters will need to be chosen in a way to provide a high level of security even in the face of a lot of churn.
Dev Outreach
On November 30, Nick is going to be speaking at the IoT + Data Decentralisation meetup in Edinburgh.
Over 3.6 billion records were stolen between 2014 and 2015, which clearly indicates that the way data is stored today requires a new approach. Not only is data that is centrally stored vulnerable to attack, but storing data in this way is expensive, because the greater the protection, the higher the operating cost. This is why companies and individuals end up spending billions every year on the infrastructure that serves our applications and that processes our data. A new breed of startups are using a different approach to the way data is stored. By tapping the unused potential of billions of connected devices it is now possible to move our data management away from large companies and their data centres. This talk will discuss how harnessing the power of the crowd will impact almost every aspect of our future daily lives including the IoT, and our relationship with the Internet in general.
In addition to the 2 events previously mentioned – Bitcoin Wednesday Amsterdam #42 (December 7) and Kick-off of the SAFE Developer Meetup in Amsterdam (December 9), Ben will give another talk at the Front-Enders Meetup in Amsterdam on December 6. He will explain how to build decentralised privacy-first web apps.
Ben will also be speaking at BOB Conf Berlin on February 24, 2017. His talk will explore the privacy-first data structures provided by the SAFE Network.
The Boston and San Francisco meetup groups have been officially renamed, too:
It’s also worth mentioning that Nikita (who works on the SAFE Core team) gave a Rust talk a few days ago. He said that he got some questions about MaidSafe’s experience on using Rust 
On December 10, he’s giving another presentation about Rust in another city. He’s also trying to schedule another talk for a quite large conference (1500+ participants, all developers and IT professionals) in Russia on April 1, 2017. He’s considering doing a technical presentation focused solely on the SAFE Network in the context of distributed networks.
Recruitment
We’ve signed up with an outsourcing company based in India to scale the frontend team. They’re based local to some team members including team leader Krishna. We’ve already received CVs from them and are in the process of filtering suitable resources to interview and hopefully bring onboard soon. It should certainly help us with the upcoming work in the frontend side with SAFE Authenticator and mobile support.
but oh well what can we do I guess…
.