Summary
Here are some of the main things to highlight this week:
- With the next release of
safe-cli, you’ll be able to installauthdby simply invoking$ safe auth install, and you’ll also be able to updateauthdwith$ safe auth update. - Various suggestions from the community during the past week have been included in the most recent update of the Data Types Refinement RFC.
- We closed the BLS board as well as the Secure Message Delivery board that was only missing its BLS dependency, and updated the roadmap
Vaults Phase 2
We announced last week that we were able to spawn a number of Vaults that connect to each other and form a section with the help of the Routing API. We ran the Client tests in SAFE Client Libs against this section and the initial results were promising. This meant that the integration between the different components such as Vault, Routing, PARSEC and quic-p2p was working as expected. However, there were some failures as well. Some of the tests were failing with RequestTimeout since the section failed to respond to some of the requests. We’ve been looking into this and with some debugging, we have more information. The vaults were run on DigitalOcean droplets and while processing a number of concurrent requests the Vault binary is sometimes killed by the OOM Killer due to unusual memory usage. We took a closer look into this and with the help of a few memory profiling tools we’ve identified that the quic-p2p thread seems to be using a lot of memory. It might be because it’s holding on to the pending messages in the message queue before they are successfully sent via the network. This is just one of our strong leads that we will continue looking into along with more debugging and performance analysis. Stay tuned for more updates!
SAFE API
We finished with adding support for downloading new releases from Amazon S3 which was needed for safe-authd assets. safe-authd is now able to update itself by checking its current version against the latest version available in S3. This is ready to be merged and released, we are just waiting for a new release of the dependency we use (self_update) for such updates, which should be available soon.
Being able to download safe-authd releases from S3 allowed us to add a couple of commands to the safe-cli for installing and updating safe-authd, which simplifies the process a lot for users. With the next release of safe-cli, you’ll be able to install authd by simply invoking $ safe auth install, and you’ll also be able to update authd with $ safe auth update.
In the last couple of days, we resumed a task we started at the end of last year which was about trying to expose the APIs in safe-api as async functions, plus trying to migrate the authd implementation to use async/await internally rather than using futures. We made some progress with having the APIs exposed as async functions (even though internally they are not yet fully async), and we’ll try to understand if the safe-nodejs bindings can be modified to now return promises when calling these async APIs. At this point, we see this as a parallel task we want to advance but we’re not treating it with really high priority, we’re just trying to learn the upcoming challenges for such a migration.
Labelled Data, Indexing and Token Authorisation
This last week has seen some refactoring around the initial rough token implementation. Moving some SAFE Client Libs functionality, along with the token, to safe-nd, where it can be properly used across our libraries, opening the door for token verification by vaults.
We’ve also increased the test coverage of token creation and simple verification, getting us something much more useful.
The plan going forward will be to finalise basic token verification in the vault ‘client handling’ code, so we have a good view of the whole process across our libraries, before then beginning to make the token actually useful, adding and verifying tokens such that we can start to deprecate the existing authentication setup.
Data Types Refinement
Various suggestions from the community during the past week have been included in the most recent update of the RFC. Thanks to @david-beinn, @tfa, @JPL, @dask, and @jlpell for the included contributions, as well as to many others for participating in the discussions.
SAFE Network App
This week the SAFE Network App Feature Tracker pinged blue as we worked on the UX designs for individual file and app data permissions.
It’s one of those areas that starts off feeling quite simple—“Yeah I’ll rattle this in a day or two”—and then the complexity rapidly unfolds—“Oh my” 
—and after slogging through the iterations it wraps round to simple again—“It took you how long?” 
.
It aims to provide nicely for what we need for the MVE, yet building out patterns that will be useful for more nuanced future use-cases, and some of the controls that will be helpful for the recipes that Data Labels can accommodate.
The efficacy of the approach can only really be proven through testing and understanding the possibilities that the system allows—which are expansive—so we’ll take the wraps off next week to get your thoughts, start simple, and build from there.
SAFE App C#
This week we made some improvements in our CI setup. These changes enable the CI to automatically create a draft GitHub release from the build pipeline when a version change PR is raised. Using the same setup, we released a new RC (Release Candidate) of the MaidSafe.SafeApp NuGet package.
We added a new API (AppConfigDirPathAsync) that developers can use to get the path from where the different configuration files are read. You can start using this API by updating your apps to the latest RC package. See the changelog file for other improvements.
We had different tools and checks in place to enforce the coding standards in the safe_app_csharp code which seemed redundant and were making code more complicated to write and understand. So, we refactored the code and made it more simple and clean.
To test real-world scenarios with the C# API and provide more confidence when using the package to develop different types of mobile and desktop apps, we are working on a setup to run the tests against a locally running vault. Some of the required work is already done in this PR. The PR contains the changes required to run the desktop tests against a local vault. Next, we will figure out the best way to do the same for mobile platforms.
Safecoin Farming
This week @danda has written a small simulation of the farming reward flow in a mock multi-section, multi-vault network starting with a single client’s PUT request. The simulation is written in an interpreted language as a quick/dirty tool for rapid prototyping and learning with no plans for public release. Observations and lessons learned from this are going into notes/discussion and ultimately will go into design docs. He has also begun diagraming the rewards flow and is starting a new RFC document specific to farming rewards that aims to provide more specifics and clarity.
@oetyng has also found time for some prototyping and discussion with other team members particularly around PARSEC integration details, and is advancing the rewards flow document, which will be incorporated into the new RFC.
Node Ageing
We progressed further implementing Elder promotion/demotion, addressing 2 more items in the list, validating trust when Adults receive updates from elders, and cleaning up unnecessary events.
We also cleaned up more of the Routing library, improved documentation and clarified names to ease its use.
BLS
As part of addressing unnecessary serialization when Routing messages are sent over the network, we addressed the last remaining issue for this project regarding incorrect message filtering.
We have now closed this project board. Any performance issues or clean up will be addressed as part of other projects if and when needed.
With that, we also closed the Secure Message Delivery board that was only missing its BLS dependency, and updated the roadmap
Useful Links
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
but thanks for sharing!
