Here are some of the main things to highlight since the last dev update:
- We have finalised a first implementation of our new quic-p2p async API, another huge step in simplifying our codebase. Work to get our libraries up to speed with the new APIs is underway.
- We have an update on the latest progress on the SAFE Network App UX.
- Work has commenced on implementing the tree CRDT in Rust.
- @JPL updated the SAFE Network Primer to include all the latest developments.
- Last Friday was @ravinderjangra’s last day at MaidSafe. We wish him all the best for his future and thank him for his involvement in the development of the SAFE Network over the last 2 years, especially everything related to the mobile apps and APIs!
This week work has begun implementing the tree CRDT in Rust. Yesterday a milestone was reached when the code correctly executed the two problematic concurrency conditions described (and solved) in the paper. Further refinements and test cases are in the works.
SAFE Client Libs and Vault integration
With the async quic-p2p development complete this week, we are now working on getting the libraries up to speed with the newer APIs from quic-p2p. Previously SAFE Client Libs had the implementation of two communication choices -
send which sends a Query and waits for a response and
send_only which just sends a Command and doesn’t wait for a response (more like the Fire-and-Forget strategy). Now all of the hassle has been moved to quic-p2p and been made much simpler with the async/await paradigm, while also making the Client Libs lighter. With that done, we will no longer be seeing the blocking error from quic-p2p that happened previously during integration, as mentioned in the previous Dev update.
Meanwhile, the Vaults have also been given an improvement where we streamlined the integration of the Vaults and Routing layer in PR#1064. All the modules inside need to use and communicate with the Routing layer which made it crucial for us to stabilise the flow of the objects. With this change, all that the Vaults would need now to achieve the same is to pass the
Network type which then holds all the logic for making the usage of Routing APIs simple.
To make the process of integration testing easier, we are also working on a minor (multi-threaded) framework under a feature-flag in Vaults that spins-up a SAFE section at the call of a function and runs the specified client-side tests that are present in the SAFE Client Libs on that section. This maintains the essence of realness of the network with real QUIC connections and with real clients, removing the need for any mock implementation and moreover making this work both ways to significantly fast track the development and integration of SCL and Vaults simultaneously.
We’ve implemented the wallet registration for reward payouts.
A node wishing to join the network is able to specify a wallet address in the config. When the node has joined a section in the network, this wallet address is sent to the Elders of the section, for the eventual payout of rewards.
SAFE Network App UX
First off, if you’re delving into the Figma files above to follow along with the latest changes you should notice a decent performance improvement
after our relentless pestering of senior Figma developers.
A few disparate updates to share with you:
App Permissions are now Capabilities
We’ve previously walked you through how you’ll be in control over your data, and how and when each app can be used by you to access it.
Until now, we’ve been calling these App Permissions. But in order to not anthropomorphise Apps, and more accurately describe what’s going on, we’re changing this to Capabilities.
So rather than giving an App Permission, to say edit an image —when really you’re just giving yourself the ability to edit the image using that app— you’ll give it the Capability to do that.
It also allows us to reserve the term Permission for when you are sharing, or managing access to data, with another user or group of people.
Floating Action Buttons now with descriptions
We’re using floating action buttons (FAB) in a number of different contexts. While the material guidelines favour just a single icon, given the number of different contexts, we felt it enhanced the clarity and usability to include an action description within the FAB, so you’ll see this change roll out through various screens and flows.
Login prompts from External Apps
We’ve also been working on flows for triggering log in events from external apps, and how these are handled, both in terms of maintaining an understandable flow when they happen, and popping the user back out into a helpful place after it’s complete.
Publishing Timer Snackbar
And a final wee update. We’ve made a change to the publishing process that includes a snackbar with a countdown timer, enabling the user a small cooling-off period before perpetual data is published. This is instead of the alternative of a short ‘undo’ window, which we’d previously mooted, and more accurately reflects what is going on behind the scenes.
As mentioned in last week’s dev update, we have been working on some Routing improvements, with two further improvements merged this week: remove bounced_unknown_messages cache and remove unnecessary send_neighbour.
There is also on-going work to remove SendNeighbourInfo votes, which currently has several random tests failing but we expect those to be resolved and merged soon.
Since last week’s debate on the relocation refactoring work (Remove relocate_queue and make relocation independent on the order of churn events), we found a promising solution which Adam has already started implementing. There are a bunch of failing tests to be overcome first (as relocation is a key feature which affects the testing framework a lot), before raising a formal PR for it.
This past week we finalised a first implementation of our new quic-p2p async API, which as in all other crates is helping immensely in simplifying our codebase. This new API follows the pattern used in the
async world, exposing a stream of messages the consumer can just iterate over asynchronously, which for us means removing any type of event loop implementation of our own. We’ve been testing this with our client libraries to make sure it fits well in our software architecture and it has been showing very good results so far.
We are now trying to do the same migration in the
routing library to not only use the new async quic-p2p API but also to expose its own API as
async, which as said above will simplify the codebase massively both in
vault crates. As you may realise this is all internal refactoring, the benefits of which can be difficult to see for end users, but we are very positive this will allow us to find and solve any issues we find in the future more easily, as well as make it easier to maintain and evolve existing features.
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!