The 3 failings tests mentioned last week have been resolved (all the tests in
routing are now passing). We're about to test a routing example application on a network of DigitalOcean droplets to make sure that the network is able to maintain its structure during churn (see the Routing & Vault section below for more details).
In parallel, we are continuing to work on implementing the 3 RFCs related to the new authentication flow + granular permission control.
We have detailed the authorisation process in the New Auth Flow RFC. Ben is lending some help by working on the Rust code (from
safe_core) so that the bindings required for the UI can be provided sooner. Shankar and Krishna are working on the SAFE Authenticator plugin and an example application just to get the development progressing without the actual integration with
We are continuing to implement MutableData and the new paradigm of Authenticator-based interaction in
We have completed the provision of RPCs in the
core module and mock-routing based on all the requests that the network allows the clients to make. The client creation functionality is in place with new MutableData and mandatory user and config root directories. We are now coding low-level (FFI) access to manipulation of MutableData, provision of standard user directories and MaidManager simulation in mock-vault for app key authentication.
Routing & Vault
The failing tests mentioned in last week's update were resolved and all the tests in the
routing crate pass now! We are preparing for the next round of testing – running a routing example application on a network of DigitalOcean droplets in order to verify that the network is able to maintain its structure during churn (turning droplets off and on again), specifically that it always restores the routing invariant.
With Disjoint Groups, the nodes are organised in groups defined by prefixes, e.g. the group with prefix
10 contains all nodes whose names in binary start with
10, and the requirement is that two nodes are connected if and only if the prefixes of their groups differ in at most one bit.
Andreas is currently writing a script to check that invariant from the droplets' logs.
We fully expect to find a few more bugs in these tests. And also, there are still a few edge cases that we have yet to write new tests for: Fraser is currently working out how to deal with simultaneous and conflicting group merge and split events, and writing a test for this scenario. (For example, the group with prefix
10 may have lost a node and need to merge with another group,
11, into a new group
1, to keep its minimum size, but at the same time group
11 may have gained a node and want to split into
111.) And in the same vein, Bart is looking into adapting Byzantine-proof (i.e. resilient against malicious nodes) consensus algorithms to help groups agree on the order in which events are processed.
The next stage will be testing actual vault binaries, but first the
safe_vault crate's mechanisms, and its unit and integration tests, need to be adapted, too. Fortunately that might turn out to be easier than expected: Diggory is currently investigating whether we can reuse almost all of the existing algorithms there! The benefits of the new "group" notion — a simple scheme to securely relay messages, better control over the number of joining nodes per group, evaluating other nodes, … — are all on the routing level and we may be able to just keep using the old "8 closest nodes"-type groups in
safe_vault (and still use the secure message routing mechanism, without
safe_vault even knowing about it).
And finally, Qi is currently detailing the concrete implementation plan for challenging new nodes to prove that they have the resources (bandwidth, storage, CPU) to contribute to the network. This will be the first part of the Node Ageing RFC.
@joshuef is done with implementing all the tasks he had planned in his SAFE Browser proposal. Krishna's team has reviewed the code. We think it's fine, we just have a few questions for @joshuef and then we intend to conclude the SAFE Browser RFP by sending him the project payment.
Ben attended DAppHack – a hackathon and unconference about decentralised systems. During the hackathon, he ported the noBackend Invoice Example App to SAFE and published it on the Test 11 network. See this topic for more details.
@happybeing submitted a pull request for a new RFC called "File Sharing By SAFE Data URI". It's a feature request to add the ability to access files using a web URI (without going via a SAFE DNS public ID and service). As @happybeing mentioned, the RFC is a joint effort between him and @lightyear.
It looks like a great RFC! But we're not able to move it forward at the moment. We want to get some fundamental stuff in the RFC process done (e.g. assigning each RFC to a shepherd – the shepherd is a trusted developer who is familiar with the process, who will help to move the RFC forward and ensure that the right people see and review it). The current process is lacking in selecting shepherds and so we're looking to get the process in place to assign shepherds to all the community RFCs soon.