Here are some of the main things to highlight since the last dev update:
- We have finished work on the vaults from home improvements and have been running internal testnets - results look good so far!
- Work continues across the board to switch our testing away from running against mocks to running against production code.
- We are integrating a further refactor to network requests, which will open the door to farming on the network.
- The Routing DKG replacement PR has been merged.
Vaults Phase 2
This week we completed implementing improvements based on the feedback received from the previous testnet. We have been testing these changes in internal testnets and we are seeing very good results. After just a little more testing, we will be ready to announce another iteration of the Vaults from home testnet, showcasing all the improvements we’ve been working on.
We’ve also been working on making our test suite run against real Routing. The tests take much longer to run, but, this is because we currently spawn a separate network for each test. We are working on some more refactors which will use the same network for all the tests and this will speed things up significantly.
A pull request for glob() support was raised this week, however, concerns over efficiency and need for further changes in subcommands for
files ls may prevent it from being merged until further work is done. This PR will go through the usual testing and review process and we’ll consider the best course of action for it.
SAFE App C#
This week we revived a slightly older pull request which focuses on Authenticator API refactoring and enhancements. In this PR, we are moving away from the
safe-client-libs/safe-authenticator-ffi and exposing the Authenticator APIs from the
safe-api crate. This will further simplify the application and authentication APIs and make it easier to keep the APIs in sync with
This week we started to do research around how to properly manage permissions in our CRDT data types, like the new
Sequence data type. Having permissions on CRDT data brings up some challenges as any changes to the access rules have to be applied in the same manner on all replicas (i.e. Elders) so we preserve data convergence. As an example, revoking permissions from a user to append items to a
Sequence may lead to having some replicas allowing the user to still append items if such operations are seen before the revocation operation, therefore having replicas not converging to the same data state.
We are looking at some available papers where some solutions are proposed, to better understand not only the solutions but the problem itself. For those interested in reading more about the problem, this paper could be of help, at least just to understand the challenge.
safe_core tests against the AT2 system, we’ve been working on integrating a further refactor to network requests to open the door to farming on the network. As we move towards a pseudo multi-section setup with AT2 and farming, vaults and sections in the network need to exchange messages among themselves to complete a data/payment flow. This raises a need for us to distinguish between client messages and intra-network messages. Therefore an overhaul has been started on the messaging structure which the network will use. Basically, this will align the messaging with CRDT principles and event driven systems.
This has in turn led to further work on the integration with SAFE Client Libs, but things are progressing well here as we uncover bugs and performance issues, and refine the messaging flow there. One more significant change to SAFE Client Libs has been the removal of “ack” type Responses (which essentially tell us nothing), and leaving it up to the client to optionally confirm whether their operation has completed. (This itself should eventually lead us to some try/check/retry flows for certain operations, but it won’t be necessary to do so. Which should give app devs more flexibility in how they proceed, and in turn hopefully make the client itself more responsive).
This week we finally merged the DKG replacement PR. This enables us to update section keys without using parsec.
To help improve code quality, we also added code coverage statistics into the crate, and enforced the rule that any further PR shall not decrease the coverage rate. As mentioned previously, we are gradually switching away from testing with mocks across all our repositories. This inevitably means that code coverage stats against production code will start off low as this has never previously been our focus, but we will gradually build that up over time.
Our current primary focus is on the tasks to remove the parsec usage. One such task currently going through the PR review process is ensure mutations to SharedState are approved by the section. We also started working on overhauling the node promotion process so that it does not involve parsec as much. That is a prerequisite for another major task, which is to implement message-based voting - with that we will replace the current parsec-based voting, which of course gave us consensus and strong order, with a much simpler mechanism which gives us consensus without order, which we believe is enough.
After releasing the first stable version of our xor-name crate last week, we continued to build on that this week by refactoring multiple crates to start using the new xor-name crate.
As it stands, we have what are now redundant XorName type and related functionalities exposed from
safe-api. To streamline the code in these repos, we are in the process of removing XorName from each, making use of the new dedicated xor-name crate instead. Draft PRs making this switch in each of these repositories can be viewed here, here and here respectively.
We are now waiting on an external crate version to be published to unblock us from proceeding further with this. Once that is available we will continue the refactoring work with
safe-vault and other repositories.
Feel free to send us translations of this dev update and we’ll list them here:
As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the SAFE Network together