Summary

Here are some of the main things to highlight this week:

We completed a refactoring in authd (the Authenticator daemon) which brings the ability to run authd on Windows without admin permissions (starting from the next release).

The safe files get command is basically complete and should be included in the next release of the SAFE CLI.

command is basically complete and should be included in the next release of the SAFE CLI. @jimcollinson posted some more candidate designs related to the SAFE Network App UX (see below).

Planning continues for Vaults Phase 2b - a multi-section network.

Vaults Phase 2

Project plan

We hope you’ve been having fun with the last release of the testnet. We’ve been doing some interesting research for some improvements to the current phase of the single-section network. In parallel, we’ve been planning the next phase with multiple sections too. We’ve added some cards to the linked project board. After some more thought, we’ll be converting them into issues with a lot more detail and then it’s code sprint time!

SAFE API

Project plan

This past week we were able to finish a refactoring in authd which changes the way the process is launched as a daemon. This refactor allowed us to get rid of two dependencies we were using for this purpose (for Windows and Linux/macOS respectively), and have the same code for all platforms as the process is spawned using native Rust utilities. With this change we were also able to fix the issue we had in Windows with authd logs not being generated at an analogous location as it’s done for Linux and macOS ( ~/.safe/authd/logs/safe-authd.log ), i.e. authd on Windows will write its logs at C:\Users\<user>\.safe\authd\logs\safe-authd.log in the next release.

Another interesting improvement this refactoring brought to authd is the ability to run authd on Windows without admin permissions. This requirement was due to authd being installed and run as a Windows service, but it will now be launched as a simple process in the background, just like it’s done on Linux and macOS. Therefore, from the next release there will be no need to install it with admin permissions on Windows, it can be launched with a simple safe auth start command, again, without admin permissions.

We’ve also made some minor fixes in the CLI, including a change to make the timeout window in the communication between the CLI and authd larger so the CLI doesn’t timeout before authd times out when it has issues connecting to the network. This way, we’ll be able to see the timeout error coming from authd rather than a CLI timeout error. We’ve also enhanced the CLI so it doesn’t fail when the credentials are invalid, and instead it fallbacks to connecting with read-only access which may be good enough for some commands like cat/dog on public content.

Finally, work has been progressing on safe files get which enables file and directory downloads from a SAFE Network FileContainer to the local filesystem. This command works similarly to cp or scp on Linux/macOS, or copy on Windows. The code is now basically complete and is being tested by the team. It should be included in the next release of the SAFE CLI.

SAFE Network App UX

MVE Feature Status Tracker

More progress on the nitty-gritty of the app’s experience. It’s not terribly glamourous, no giant leaps here, but all more flows being chalked off the list.

Give them a tap or a click and a download to peruse in full resolution:

The Data Access Feed

Multiple data in a single permission request

Filtering and sorting lists

SAFE Network App (desktop)

Project plan

Work on the SAFE Network App has largely been on hold this week as @joshuef has been diving into the client libs to take a look at some CRDT conceptual work. This itself involved a bit of a refactor of our connection management code to enable simpler testing of response handling. Once that was in we’ve gotten a simple GSet example test suite set up and we can see that receiving/merging some disparate CRDT types of data shouldn’t be too much trouble client side. Once more, that’s only a quick proof of concept, but it is looking promising thus far.

With that in the bag, we’ve started looking to address some of the issues reported in the previous week’s update here. Linux appears to have been having quite the time, so we’re starting there. A new alpha should follow along shortly, so our avid alpha testers should get notified in-app when an update is available but we’ll also post something here to let you know.

SAFE Authenticator / SAFE Browser (mobile)

Authenticator Project plan, Browser Project Plan

We made a couple of textual changes in the authenticator app, mostly focused on the network selection page. On the mobile browser side, we noticed that some of the websites/pages are not loading properly in the iOS app while working fine on Android devices. We are in the process of finding the root cause behind this issue so it can be resolved.

Other than regular bug fixes, we are working with the SAFE Client Libs team to provide a better user experience around network disconnects and reconnects. This will help us in properly handling the different network events and we will be able to remove unnecessary re-authentication steps.

SAFE App C#

Project plan

We fixed a long-standing bug in the safe_app_csharp library. The bug was resulting in an app crash when trying to decode any authentication response from the authentication app (mobile or CLI). Because of this bug, it was not possible to handle different error cases. We also updated the tests to ensure the proper working of the fixed API on all desktop and mobile platforms.

We removed the AppVeyor test setup from the repo and to further simplify the process and use a single platform for all the CI/CD process, we are moving the code coverage and API documentation publish setup to the Azure DevOps pipeline.

Routing and quic-p2p

Routing Project Plan

The Routing work is paused this week as we’ve been exploring a new exciting algorithm that can potentially significantly improve the coin handling logic in terms of performance and code simplicity. Can’t say much more than that yet but stay tuned for more info!

BLS - Distributed Key Generation

As planned since last week, we added more unit tests to the work on the PoC implementation. These tests expand the coverage of the whole transition phases among the DKG proposal and demonstrate more usage cases. We also fixed some bugs encountered in this process and updated the code with a neater testing structure.

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