Yesterday, we had to restart TEST 9 because of a bug in churn handling that ended up taking all the nodes offline.

SAFE Network TEST 9 + SAFE Mail Tutorial For testing purposes, we make the nodes crash immediately for certain types of errors. We obviously wouldn’t do that in production code, instead we would simply make the nodes print error messages. But for testnets, making the nodes fail fast instead of printing error messages can help us catch bugs faster. In this case, it helped us catch a small bug in safe_vault . You can see the fix here. All accounts and data have been reset, therefore you will need to create a new account with SAFE Launcher. You can keep using the same version of SAFE Launcher (v0.9.0).

SAFE API Docs

Today we are releasing the new SAFE API Docs website We agreed to use GitBook to build and host the API Docs. The source code of the API Docs is hosted on GitHub. Anyone can easily submit a pull request by forking this GitHub repository.

The API Docs currently cover SAFE Launcher API v0.5. The new low-level APIs haven’t been added to the API Docs yet, since they are part of SAFE Launcher API v0.6, which is not ready yet. Krishna is working on a pull request to update RFC 42 – SAFE Launcher API v0.6. We will start working on the next version of the API Docs (v0.6) once that pull request has been merged.

Click here to access the new SAFE API Docs

SAFE Launcher

The implementation of the low-level APIs is being tested and will be followed up with bug fixes in the next couple of days. We also fixed a few UI bugs and improved the packaging process. CI suite has been integrated, we just need to test on Windows too. The unit tests are back and functioning (the Authorization, NFS and DNS APIs are covered by the tests).

We are currently working on integrating the SAFE Beaker Browser with the APIs required for the next example app. We are aiming to release the second Dev Tutorial next week

SAFE Core

We are currently involved in 3 active topics on the Dev Forum:

We welcome developers to voice their concerns and get involved in the discussions.

We have looked into the discussions so far and are now in the position to evaluate the merits of all the proposed approaches and community feedback put together. We will soon post a summary in each of the 3 topics. These discussions have had nice amount of details and involvement and have been helpful in allowing us to better understand the requirements.

Apart from the changes in directory structure and versioning and others as discussed in those topics, we are also looking into an async-refactor of safe_core and self_encryption crates.

A few newer APIs wanted by Launcher, like ownership assertion, version field exposure etc. have been added too.

Routing & Vault

We are currently discussing and writing several RFCs. Andreas is going on vacation for 2 weeks starting this Wednesday, so we are trying to make as many decisions as possible before he leaves. We also have two new team members joining soon, and are making plans for onboarding them. That is why the disjoint groups implementation has been paused in the past few days, and will continue later this week.

With the new RFCs we will try to answer in as much detail as possible the remaining big questions for routing and vault. Even if the implementation of some of them is still a long way away, we want to make sure that we are moving in the right direction and avoid writing code that is going to be rewritten later again. Some of the ideas are:

Merkle tree of node keys: Periodically compute a hash of all nodes in the network which allows every node to prove its identity to any other node in the network and avoids the slowdown for group messages that comes with the original Disjoint Groups RFC.

Node monitoring: Neighbouring groups evaluate the performance of nodes in terms of bandwidth and verify that the right messages were sent, so that we can detect and ban malfunctioning and slow nodes.

Profiling joining nodes: Qi is working on measuring the bandwidth, CPU and storage of a new node before it joins the network. This is an alternative to RFC 44 – Relay Nodes and it’s probably simpler to implement.

Data node names: Fraser is exploring ways to give two names to each node, one as a data holder and one as a group member that votes in consensus decisions. That is a prerequisite for relocating nodes periodically without causing all the data to be relocated, too – an approach that will likely be necessary to prevent a particular type of Sybil attack on the network.

Recovery from broken groups: The network needs to be prepared for the extreme case of complete groups of nodes breaking (i.e. enough of them malfunction to prevent consensus). In such a case, the surrounding groups will recover the data – which should be possible even if only one functional node remains – and remove the broken group.

All these RFCs have required a lot of discussions in the last few days (several hangouts with up to 9 of us happening and several of these are lasting over 4-6 hours). We are doing a lot of upfront work (designing & reviewing RFCs) prior to working on the implementations (the easier part ).