Summary
Here are some of the main things to highlight since the last dev update:
- We released new versions of the SAFE CLI (v0.12.0) and the Authenticator daemon (v0.0.8). The CLI now includes a
files getsubcommand and the Authenticator daemon doesn’t require admin permissions anymore on Windows. - We released a new alpha version of the SAFE Network App.
- We released v0.5.0 of the SAFE Mobile Browser which includes the required changes to provide an in-app update feature.
- We recently created a general guide to contributing which we now link to from each repository’s README.md file.
Vaults Phase 2
We have now started development towards the next phase of Baby Fleming - Vaults Phase 2b, a multi-section network. We have a few tasks lined up on our project board and the first pull request is already up! This PR implements the behaviour of new Vaults joining the section as Adults which are later promoted to Elders if required. The next step is giving Adults the responsibility of holding ImmutableData chunks. We have started implementing this as well. Exciting times ahead!
SAFE API
Earlier this week we released new versions of the SAFE CLI (v0.12.0) and the Authenticator daemon (v0.0.8) which bring several enhancements to the codebase, some bug fixes that were recently reported by the community when testing with the Baby Fleming network, as well as some new features such as the ability to download files from the network onto a local path with the introduction of the files get subcommand.
One important enhancement made to this new version of safe-authd is that it neither requires admin permissions for running it on Windows, nor a need to install it as a Windows Service before being able to start the daemon. Now safe-authd can be started with the single safe auth start CLI command on Windows, just as is done on other platforms.
As always, you can update your CLI with the safe update command, and safe-authd with safe auth update. Just one note for Windows users: before updating and running the new safe-authd version, please first uninstall the Windows Service of the old version of safe-authd using old safe-cli (i.e. version <= v0.11.0). This can be done with Windows admin permissions and running safe auth stop followed by safe auth uninstall.
CRDT
We’ve started looking into CRDT for managing our base data types in an effort to avoid the need for strictly ordered consensus here. This is looking very promising for our underlying data types, and we’re aiming to augment the MutableData and AppendOnlyData types, while keeping the APIs as similar as possible there.
The benefit here would be much more throughput when adding data to, or modifying data on the network, as this was shown to be a bit of a bottleneck with our newborn Baby Fleming.
As a first step into trying to have our first CRDT data type, we started working on a PoC implementation of a Sequence CRDT based on the proposed LSeq CRDT. We’ve just started with this during the last few days and we are trying to get a first basic implementation which can be tested to confirm it can work in our setup where each CRDT replica is held by an Elder in the section. We are in the early stages of this, thus we still need to confirm this CRDT will cover all our needs as we initially thought. Once this shows us some good results we’ll start with the integration of it in all layers from vault, through APIs and CLI.
As hinted at last week, we’ve been looking at how safecoin could benefit from similar measures, and we’ve come across quite the interesting paper on something known as Asynchronous Trustworthy Transfers. The crux of the matter there is that we can verifiably remove the need for ordered consensus on transactions within our sections, which means one less thing to be co-ordinating on amongst our nodes. Right now we’re working this into our initial safecoin implementations, but it’s looking like a promising avenue to keep consensus, simplify transactions and the code base while increasing throughput!
SAFE Network App (desktop)
As promised, just after the update last week we got a new alpha release of the SAFE Network App. See this post for more info on the changes.
SAFE Authenticator / SAFE Browser (mobile)
Authenticator Project plan, Browser Project Plan
This week we worked on a small yet exciting feature. Our target was to improve our CI/CD setup and integrate the mobile apps with the AppCenter distribution SDK. In simple terms, our goal is that if you already have a SAFE mobile app installed on your device with these new changes, and a new version of the app is released, the app will prompt you to automatically update to the latest version. No more manual downloading of the app from GitHub or AppCenter. This week we successfully tested a PoC for different use cases, and so implemented this new feature in the mobile Browser app.
Today we released v0.5.0 of the mobile Browser 
You can download this new version using download links/QR code from the README file. The latest release includes the required changes to provide the in-app update feature - once you have manually installed/updated the Browser app to v0.5.0, all future updates can be handled within the app.
Some users may prefer to stick with manually updating at a time of their choice - if you want to manually download and install updates to the Browser without getting any update notifications, you can disable the auto updates from the settings page.
Our next steps will be to follow mobile Browser app version 0.5.0 with 0.5.1. We intend to release this new version next week. This will give us, and you, a chance to try out this auto-update feature on various devices and environments. There are still some clarifications we need to make around how updates work on iOS in particular: we believe that iOS users may need to sign into AppCenter for the auto-update to work. How convenient this will be compared to the current process is something we will assess with your help. If all goes well, we will then be adding this feature to the mobile Authenticator app.
Routing and quic-p2p
After last week’s detour to research the AT2 algorithm (more details in the CRDT section of this dev update), we are back this week to working on Routing proper. We mentioned a couple of times in the past that we want to improve the test suite. This week we finally took the first step towards that. We removed some unrealistic assumptions about synchronicity and brought the tests closer to reality. The work isn’t merged yet but it’s already proved itself useful: it uncovered two bugs which sneaked through the old test suite. They are both pretty unlikely to occur in the real world but it’s best to have even such edge cases covered. Both bugs were fixed in the same PR which is currently being reviewed and we expect it to be merged soon.
BLS - Distributed Key Generation
As the first big step towards achieving a workable DKG crate, this PoC PR was merged this week. This PR included some tests which also serve as usage examples. PRs with further test scenarios are in the pipeline here and here, all designed to ensure the crate works as expected. We are also working on some API updates to allow other crates to easily use DKG. In parallel to these, we are investigating making use of a Routing like simulation tool, similar to the one here which we’ve used previously. Our aim with this would be to check the DKG crate’s usability within a churning section, i.e. having membership regularly changing.
QA
We are always looking for ways to break down barriers for the community and beyond to contribute to our project. We recently created a general guide to contributing which we now link to from each repository’s README.md file, and in the last week we have added bug report and feature request templates to each repository. Small and simple additions, but we hope they prove valuable over time.
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
And the forum members testing 
