Here are some of the main things to highlight since the last dev update:
- We made the sn_fs GitHub repository public and encourage the more technical members of the community to try mounting a filesystem.
sn_apirepo is now building against our updated
- Node and Client integration work took another leap forward with, amongst other things, a PR introducing
DebitProofAggregatorto complete the work for AT2 Transfers client-side, meaning the code for a secure and successful money transfer would be considered done when merged!
- There was some great refactoring progress in
sn_routingthis week, with the prime benefit being that we are now able to quickly and easily bulk up our test suite.
This week the team kicked the tyres of the sn_fs PoC a fair bit on Linux (Ubuntu), and a couple of brave souls even tried it out on macOS. One minor issue was identified and fixed on Linux. Unfortunately on macOS, several issues were reported that are not yet fixed, so we do not yet advise using it on that platform, although it does build and run, and some basic functionality did work. The code cannot be built for Windows at all yet.
Nevertheless, this week we are pleased to make the sn_fs GitHub repository public so that technical members of the community can build it and try it out and/or review the code. Build and mount instructions can be found in the readme. Please report any issues in its GitHub issues page with all the relevant details.
A reminder: sn_fs is a proof-of-concept to demonstrate that crdt_tree is viable for building a local caching filesystem. As such, there is presently no networking and no integration with the Safe Network itself and everything is subject to change.
This week we’ve been updating the
sn_api crates (
authd) with the massive changes we’ve seen from
sn_client. A lot has changed there since it was
safe-client-libs, including messaging and data type naming as well our transfer system. It’s been quite the batch of changes but the
sn_api repo is now building against our updated
sn_client and we’re ensuring tests are all in a good place for when we have that client fully functional against the nodes.
On the integration side of things, Node and Client modules have seen multiple fixes going in this week. With PR#245 in
sn_data_types merged, a handful of bugs were fixed that affected the Node regarding IDs, keys and message signing. These changes were reflected in Node PR#1128 and Client PR#1271. Once this is merged, Clients will be seeing a bit more action with the introduction of
DebitProofAggregator, which completes the work for AT2 Transfers client-side. This is the last piece in the Transfers puzzle that is required to accumulate and aggregate SignatureShares from section Elders to produce a
DebitAgreementProof for a secure and successful money transfer.
Looking ahead, once the above PRs are merged we should see more than half of the e2e tests going green right off the bat. With a few minor fixes and cleanups we will increase the stability of these two crux modules to work in sync. Next steps after fixing the remaining test suite issues is to expand the farming integration tests, complement the whole set with chaos testing, and integrate these updates with the qp2p IGD updates that were mentioned last week (which re-enables the “Nodes from home” concept)…then freeze the code for a testnet!
This week we continued refactoring routing in order to make it simpler, easier to test, and easier to reason about. First we landed a PR that removed the somehow confusing
PublicId types. We now use more industry-recognised
Keypair instead. This was followed up by another PR to clean things up a bit more. We then landed another PR which refactors the internal logic using a command-driven paradigm and which allows us to re-structure the code into a couple of small, self-contained and loosely coupled components. Most importantly, it makes the code more easily testable. We already wrote a bunch of new unit tests using this approach and they were a breeze. This is quickly closing the test-coverage gap created by removing the old mock-network based tests which were too complex and unwieldy.
On the CRDT front, we continued with testing the PoC code we have for section membership data. We were creating different tests and fixing issues we discovered along the way. We are now looking at and trying to understand the effects of some more complex scenarios when it comes to section churns, and how we can deal with them, using CRDT logic. Thus this is where we’ll be focusing in the next few days by creating some tests which can reproduce these scenarios and finding a solution for them.
In parallel, we are starting to look at how the new CRDT-based membership data can be integrated into the routing codebase and its business logic, which implies finalising the internal APIs of our PoC code.
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!