Summary
Here are some of the main things to highlight since the last dev update:
- We are working on an automated process that creates nodes, joins an internal testnet, stores data and churns the nodes. This will allow us to scale up our testing of sections.
- We have finalised a first implementation (PR #186) of supporting concurrent Policy mutations with Sequence items mutations and can now start making the changes in safe-vault and client libraries to adapt to some minor changes we made to the Sequence requests types.
- Community member @happybeing has been investigating FUSE filesystem options in Rust, and has started a draft document proposing a safe-fs API. Discussion is ongoing here.
- We have implemented a full continuous delivery pipeline in our safe-nd Rust crate.
Vaults Phase 2
Weāve been continuing our study on the memory usage of vaults and we have some interesting results. The issue we uncovered isnāt something that was happening throughout the execution of the process. The issue was because the OOM killer terminated the vault process before deallocating the memory in use by the vault. So it boiled down to looking at the different components of Vaults and their memory usage.
We identified two components with high memory usage. One of them is PARSEC. We are already aware of this and as you will be aware, its removal and replacement is already in progress. The other component with reasonably high memory usage was quic-p2p. We dived into the crate and identified that we were sending a copy of all messages back to the user of quic-p2p. This is useful when the sending of a message fails, but, for successful sends we do not need to send back a copy of the message. Removing this alone reduced the memory usage significantly.
We will continue working on such fixes and improvements and carry on with testnets to help identify issues in the network and its performance. However, we will be keeping these testnets internal for now. We are working on a testing setup that creates nodes, joins the network, stores data and churns too. This will allow us to scale up our testing on our testnets and find weaknesses ASAP. This will be fully automated so we donāt anticipate needing to run manual community testnets in the short term. We anticipate that the next community testnet we do set up will be feature-packed with the new kids on the block, i.e. CRDT, AT2 and farming, or at least a subset of these.
SAFE Browser / SAFE Authenticator (mobile)
Browser Project Plan
Authenticator Project plan
We refactored the authenticator app to reuse the authenticator APIs from the NuGet package and drop its own implementation of the FFI wrapper. This step removed lots of redundant code, tests and trimmed down the CI/CD setup.
In parallel, we updated the mobile browser to support the latest CLI/vaults. We tested both apps against locally running testnets and fixed a few issues we found during tests. There are few changes pending in the authenticator app. Once completed, both apps will be ready to use with the new vaults.
SAFE API
There hasnāt been much activity on this repo this past week, only some maintenance activities. Nevertheless, we will soon be trying to implement some bug fixes as well as making sure itās up to date with changes being made to the client libraries.
CRDT
Weāve finalised a first implementation (PR #186) of supporting concurrent Policy mutations with Sequence items mutations. This first approach allows different branches of the Sequence to be created for each new Policy that is set, e.g. if a client is working offline making data mutations without being aware of a new Policy being set to the content, when the client goes back online and broadcasts such operations to the network, they will still be applied but in a new branch of the Sequence. When retrieving the items from a Sequence, the items corresponding to the āmainā branch will be by default read, but eventually we can allow clients (through a different type of API/request) to also retrieve items from any of the other branches that could have been formed from each previous Policies.
This first implementation is giving us a good start where we are covering all the potential scenarios where clients are appending items to a Sequence while some other client/s may be setting a new Policy concurrently. From a user perspective, this can be seen simply as a Policy mutation always winning over a concurrent data mutation, since such data mutation will still be applied but as belonging to a branch formed from a previous Policy, which is the Policy that such a client would have been aware of when sending the data mutation request.
We will now start making the changes in safe-vault and client libraries to adapt to some minor changes we made to the Sequence requests types. E.g., one of such changes was merging the ownership and permissions to be all part of a Policy rather than being separate attributes of a Sequence. Changing ownership or setting permissions for other keys is now made by simply setting a new Policy for the Sequence. We will anyway work on exposing APIs which allow users to have more flexibility and granularity for changing ownership and setting permissions to a Sequence.
tree-crdt
Work has continued on the experimental tree-crdt code described last week. We implemented the suggested execution optimisation from the crdt-tree paper as well as an index to quickly lookup a nodeās children. We added lamport+actor timestamps, which means this code can now work correctly when running from separate processes (without sharing a clock). We also fixed an issue with duplicate operations entering the log if they have the same timestamp, plus added several test cases.
Most recently, we implemented log truncation (discarding old operations) as described in the paper. This prevents the operation log from just growing forever. For correctness, this method requires knowing the full set of all replicas, which is problematic for SAFE Network usage, considering each user-agent is a replica and there is also vault churn. Further investigation will be needed to find a good enough truncation strategy, but this does not seem a showstopper and can be revisited later in the development process.
In collaboration, community member @happybeing has been investigating FUSE filesystem options in Rust, and has started a draft document proposing a safe-fs API. Discussion is ongoing here.
Transfers
SAFE Transfers Project plan
SAFE Farming Project plan
SAFE Client Libs Project plan
SAFE Vault Project plan
As has been noticed on the forum, thereāve been a lot of things ironed out with regards to paying for data, farming algorithm, and rewarding nodes for storage of data.
We are working intensely on confirming there is no regression after the integration of transfers, farming and the resulting messaging / modules refactor of safe-vault, with the aim to quickly move over to this as the working branch. Work has started to update SCL to be compatible with these new farming vaults as a load of structural improvements have been done to the vault modules and network messaging.
Routing
Since last week, we have focused on some feature refactoring tasks to prepare for PARSEC removal. These include the resolvement of an issue to improve message signature accumulation to not implicitly require PARSEC (which is mainly addressed by the Routing PR to notify lagging elders and the safe-network-signature-aggregator PR to avoid mixing different public_key signed), and on-going work on an issue to change NeighbourInfo sending and receiving to not require accumulation (covered by the Routing PR to remove SendNeighbourInfo votes). There are not many feature refactoring tasks left over on our TODO list, and so the formal work of PARSEC removal is expected to be started soon.
Some other good news this week is that thanks to the newly released 0.4.0 threshold_crypto, there is no longer a need to support different versions of the rand crate. The merged PR update deps and refactor code to simplify rand crate usage took away one more unnecessary complexity.
Continuous Delivery
Weāve been on the cusp of enabling continuous delivery (CD) for a while now. The SAFE Browser has automated releases, but weāve been battling GitHub Actions in order to automate version bumps, changelog updates, tags and releases.
In the last week, weāve taken some of the learnings from the SAFE Browser and applied those to one of our Rust libraries, with the aim of getting CD going there. This was a bit of a slog with a fun array of issues to contend with there (you cannot automate pushes to protected branches on GitHub, canāt review your own pull request, canāt get the commit message of a PR easily). Buttt, weāve overcome all of this and have, at last, a new action for our Rust repos to automate version bumps and generate changelogs (from conventional commits). This automatically generates a PR for the version bump, and we then have another action that merges that. Which then (once again in master) will tag the new version and kick off releases for us. All automagically 
It is very satisfying to finally have this process in place, working, and a decided improvement over the need to manually manage version numbering, changelogs and releases across repos. Weāve implemented this CD process in the safe-nd crate initially, with the intention of giving it a little time to bed in and ensure it all works smoothly, before rolling it out to other libraries.
Useful Links
Feel free to reply below with links to translations of this dev update and moderators will add 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!
.
.