Here are some of the main things to highlight since the last dev update:
- The CRDT Tree repo has now been made public, and the crate has been published on crates.io
- Refactoring Routing and Vault codebase to make use of
asynccontinues to progress well.
- Routing relocation refactoring work and parsec removal will be combined into a single PR, with this now in the final stages of development.
- We have a behind the curtain sneak preview of the SAFE Network App ‘Action Menu’ UX.
This week was spent writing correctness tests for the Tree CRDT data type as well as minor refactoring to make the API cleaner and reduce the number of clone() calls. All aspects of CRDT (idempotency, commutativity, associativity) now pass tests, as well as other Tree specific tests specified in the academic paper. A crdt_tree repo has been created on GitHub and the crate published on crates.io
With the Tree CRDT basically complete, focus can now turn to the filesystem layer that will make use of it.
SAFE Client Libs and Vault
SAFE Client Libs and Vault integration
In the last week, alongside some smaller changes to be ready for the new async quic-p2p, and some tidying up of repo CI, we’ve been working on improving message handling in the client. The basic refactor work got us to a point where we could receive query responses from the whole section, though this presented issues if a response from one elder didn’t come through (we’d never get any response… despite actually having six). As such we’ve used some of Rust’s
future goodness to check which responses we have as they come in, and then choose the most appropriate responses from those we get from elders. This gets us closer to a ‘quorum’ version of the response, and means we can return this as soon as we have it, without having to wait for all 7 elders to respond.
Another change is coming in the way of how we handle Notifications from the network at Client-side. Previously, we had only one quic-p2p connection from the clients to the vaults by which all means of communications happen (Requests/Responses and Notifications). But now with quic-p2p being updated to async and allowing us to create multiple connections to a node, we can make use of this advantage by having two connections, a primary one that will be used for sending Requests then awaiting Responses, and a secondary connection on which we only listen in for Notifications. Notifications are something that we might receive even without getting involved. For example, somebody crediting our wallet with coins is not something of our doing, but we would still receive the notification. Therefore it should be a connection that must be open all the time while we are connected, and we cannot use the primary connection for the same reason as it’d be pretty active awaiting its own Responses.
Vaults async and tests
Refactoring Routing and Vault codebase to make use of
async has been progressing well. We were able to start using the quic-p2p new async API and we have Routing also already exposing an async API the Vault consumes to receive network messages. We are currently trying to finish hooking up the Routing message handling logic into this new implementation. We have so far been able to get clients and vaults to talk to each other and are almost done with re-enabling the bootstrapping process, which is what we’ll be working on in the next few days.
Since we are working in parallel on the whole stack, from quic-p2p, through Routing layer, and Vault, as we progress and test all these changes we make adjustments to any of those layers as necessary, which is what we’ve recently done to the new quic-p2p async API when testing the vaults trying to bootstrap.
First of all, the
fleming Routing branch has now been merged into the
master branch, and
master branch set as the default repository branch. We created a
pre-fleming tag as a reference point for the previous
master branch code base. We believe it is time to take this step as we are getting closer to our fleming goals in Routing, and to be consistent with other crates to avoid any confusion.
During last week’s work of using the Vault’s testing framework to verify Routing’s behaviour under real network usage, we spotted some issues. The first was related to dkg_voter, which the PR to record completed DKG section_key_index has resolved. Another issue is that we are resetting parsec on the consensus of SectionInfo and OurKey, but those are not parsec events anymore, which means they are not strongly ordered relative to other events. This shall be resolved once we have parsec removed.
We have also been working to improve the DKGVoter’s resistance against the malice attack in the Accumulate DKGOldElders messages PR, which was merged today.
Relocation refactoring work continues, with Adam making great progress there. While resolving failing tests, it was realised it would make sense to remove parsec at the same time, in the same PR, as splitting the work turns out to be particularly tricky and a waste of resource trying to make it work with parsec still in place. So, the final PR, not quite ready to officially raise yet, will contain both the work of relocation refactoring PLUS parsec removal. Adam will be taking next week off, so this work will be handed over to Qi to finalise.
SAFE Network App UX
This week we take you behind the curtain on a feature that is midway through the design process. You won’t find it in the Screens and Flows link above, but it ticks quite a number of boxes on the todo list on the way to the Minimum Viable Experience (MVE) we are building, and could prove to be quite a useful design pattern, especially when we start the jump into desktop UIs.
It’s what we are calling the ‘Action Menu’. A navigation system for the SAFE Network App that gives both access to some of the outliers in the information architecture and allows quicker access to regularly repeated actions, while also providing a mildly text command driven interface to boot. Let’s take a look.
The Action Menu is accessed from the big fat button bottom left…
The items in this menu can be clicked/tapped through to underlying menu items, in the way you might expect…
But here’s where it starts to get fun, that input bar at the top allows me to take a more text driven approach, searching through menu items and commands
And I can take that even further by typing a more specific natural language command. In this example, I’m transferring some funds from my wallet to a friend:
Which would then skip me right to the end of a payment flow, with an amendable summary, ready to send
Plus, I can get a history of what I’ve searched for here for quick access to recent actions
On top of all that, I can do things like pin actions to the menu homescreen, for even more rapid access to commands I want readily at hand
Also, as a wee extra you might notice with the action menu open, is that the close button at the bottom left can be dragged/wiped to log the user out of their session.
The idea is to extend this gesture to the action menu button itself, allowing the user to hold and swipe it to rapidly log out from almost anywhere in the app.
So there we are, I hope you like the sneaky peak. It’s still pretty raw, but will be refined and iterated over the coming weeks. Let us know what you think!
You will have read about ongoing standardisation work in last week’s update, this week some further work has commenced around repository and crate naming conventions. We have toed and froed over the years between different case conventions and ended up with somewhat of a mix between snake_case and kebab-case. It was previously our intention to standardise on kebab-case, however this led to complications in Rust, which converts
_ in some cases, and so most crate names remained with snake_case. We concluded this week that we should switch all crate and repository names to snake_case to finally standardise this across the board.
In addition to this, we also decided that our crate and repository names were, in some cases, inconsistent, no longer accurate, or unclear given the changes in our code structure over the years, particularly recently. We will be going through each crate and repository and renaming where appropriate. Any which are SAFE Network specific will be prefixed with
These changes will be made in the background over the coming days/weeks.
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!