Summary
Here are some of the main things to highlight since the last dev update:
-
Today we released v0.5.1 of the mobile Browser, and v0.3.1 of the mobile Authenticator
- The initial implementation of Vault Phase 2b Adults and their behaviour while handling Immutable Data requests has been completed.
- We have our first PoC Sequence data type implemented as a CRDT and are able to start integrating it in the libraries stack.
- We now have a test version of AT2 working well with the CLI.
- A PR to add UPnP to quic-p2p is now under review - this brings connecting vaults from different homes into a single section much closer.
- @jimcollinson started working on refinements to the candidate designs he shared previously (see the SAFE Network App UX section).
A quick note to say that Nikita finished his contract with MaidSafe this week, with his final contribution being the submission of this UPnP PR in quic-p2p (discussed further in the quic-p2p section below). Nikita has worked for MaidSafe for 4 years and I’m sure you will agree he has made a huge contribution to our project in that time. Last year Nikita switched to part-time to be able to spend time on his own projects, and he believes now is the right time for him to take the leap and change direction. We know he won’t like being mentioned like this 
but please join us in thanking @nbaksalyar for his contributions over the years and wishing him the very best success in the future.
Vaults Phase 2
The past week we have continued progressing nicely towards our next Phase. We have completed the initial implementation of Adults and their behaviour while handling Immutable Data requests. The next step is to design and implement the way the section behaves during section splits.
We have some additional hands helping us progress development in Vaults. @ravinderjangra has joined us to help design and implement various features required for the next phase. @oetyng has also been helping, starting off with a refactor of the client handler which has been merged today. We are excited for the days ahead and we hope you are too.
SAFE API
Some refactoring has been taking place in our safe-api repo, specifically to the XorUrlEncoder API which is used to manage SAFE-URLs. We are adding some more functions to it so it can be used by any developer to deal with SAFE-URLs, i.e. both NRS-URLs and XOR-URLs, to parse, manipulate and also generate the corresponding XOR-URLs if needed. This is not affecting any of the functionality exposed by the CLI but just that specific API.
CRDT
As mentioned over the last few weeks, we’ve been trying to get a first PoC Sequence data type implemented as a CRDT and we now seem to have something that is functional and good enough to start integrating it in the libraries stack. This is why we have now started working on the implementations required to expose such a Sequence data type on our core libraries, starting from safe-nd and safe-vault. We are planning to add support for this new data type in the full stack without removing or changing any of the current data types or operations supported, but instead, having it first as an additional data type which we can use to start validating and testing e2e in a single-section network environment.
Once this new data type is fully integrated and validated, we’ll then start migrating all our client APIs which make use of the AppendOnlyData to start using the Sequence data type. E.g. FilesContainers and NRS Containers are currently stored as AppendOnlyData and they will be migrated to use the Sequence data type. This won’t affect how the API is exposed, nor the CLI commands, but just how that content is stored on the network.
As we’ve done with other data types, we will aim at having the public version of the Sequence fully working first, before trying to expose the private (a.k.a. unpublished) scope of it.
Otherwise, our initial AT2 implementation is looking like a solid replacement for the current safecoin implementation. We have a test version working well with the CLI, and we’re now working around the edge cases in the SCL tests themselves to ensure this is solid. From there, we’ll be looking at the next steps for AT2 which will include gossipping between nodes to ensure all updates are passed on, which should also enable double spend protection.
SAFE Network App UX
If you’ve been keeping an eye on the SAFE Network App feature tracker, you’ll notice quite a sea of green in the Essential Features row. That’s good news of course, but it also means we need to start pulling this puppy together.
Up until now, it’s been designed and prototyped around some pretty stock componentry, with the Material Design system underpinning it. This was the pragmatic choice to enable us to relatively rapidly build out a multi-platform app which is usable, familiar, and without too much of a maintenance overhead.
This approach does introduce some constraints of course — on the whole design constraints are a good thing though — the major drawback being, well, the unavoidably Googley vibes, and a little less control over the aesthetic.
Overall, this is a tradeoff worth making, given the team size, and the overall mission. But now as the time approaches to broaden out the design to further platforms (if you may recall, we’ve approached this mobile first) it’s a sensible point to put some time into the overall look and feel of the UI. It will avoid duplication of work as we move between platforms, and also allows time for the design to mature iteratively too.
So, here’s some of the rough criteria we’re working towards, when starting the upper UI layers, and adding that satisfying sparkle:
- The designs should prioritise usability, and functionality above all else.
- They should translate well across platforms, utilising core OS elements where required for native usability.
- They should also have a familiar SAFE feel, taking cues from existing brand assets, having enough uniqueness to orient users but not at the expense of 1 and 2.
- Thought should be given to adapting to multilingual options when the time comes.
- Maintenance overheads should be kept low.
- Iterative, incremental improvements, rather than big bangs.
So with that in mind, here are some sneaky peeks at the progress so far. As our first pass, we’re taking the existing prototypes and bending the Material System as far as is practicable, thinking about typography, depth, transparency, basic shapes, colour, as well as a smattering of texture too.
The idea here is to take some cues from the work we did on the website, while keeping utility and usability as priority. So a little less rad, and a little more workmanlike.
This will all keep on evolving as we iterate week by week as hands get dirtier, and of course when we are able to resume testing with users.
Futures in Rust
Last week saw us start some larger refactoring to bring us inline with modern Rust conventions on futures. We’ve started the process of moving SAFE Client Libs over to standard library futures and the latest version of tokio, too. This is no small task, but has been progressing well. As part of this we had to do a similar futures update in the Self Encryption library, which SCL depends upon, and now that we’ve unblocked that we’re continuing with changes in SCL.
SAFE Browser / SAFE Authenticator (mobile)
Browser Project Plan
Authenticator Project plan
Today we released v0.5.1 of the mobile Browser, and v0.3.1 of the mobile Authenticator
You may recall that the recent v0.5.0 release of the mobile Browser included auto-update for the first time, as detailed here. Today’s release of mobile Browser v0.5.1 gives you the first opportunity to see this auto-update process in action, if you currently have v0.5.0 installed.
To auto-update, you should launch Browser v0.5.0, then move the Browser to the background, e.g. by returning to your device’s home screen. When you then resume the Browser it should prompt you to update to the new version. Note that we were expecting a prompt to update on app launch, and not to have to move the app to the background and then resume it. We have raised an issue in the project here to investigate why this is not happening.
If you currently have a Browser version < v0.5.0, or you do not have the Browser on your device yet, you can download the latest version using the download links/QR code from the README file.
In this latest Browser release, we updated the files container page to include links to files. The user can now fetch the files from the files container using any nrs or xorurl. We made some textual changes in the authentication dialog popup to make the authentication step clearer. We also updated multiple error dialogs throughout the app to be more precise, which should make it easier for users to understand the problem and troubleshoot. Finally, the FAQ link in the app’s settings page was also updated to the correct forum thread.
Alongside the Browser, we also released v0.3.1 of the mobile Authenticator app today. Note that the mobile Authenticator app does not include auto-update - this app is being used as a temporary measure to authenticate, with the medium term plan being to roll this authentication process up into the SAFE Network App, so we have not spent unnecessary time including auto-update in it.
Authenticator v0.3.1 includes some small updates to the text used throughout the app, to make it consistent with the Browser and more accurate for the current stage of the project, i.e. we are now connecting to networks, not a single vault as we were in Vaults phase 2a.
You can download the latest version using the download links/QR code from the README file.
Routing and quic-p2p
We are currently addressing some areas in Routing that were too strict in tests and had become less relevant to the real world (assumption that all nodes see the same network at a common point in time). In addition, naming conventions are being addressed at pace, this allows a much wider audience to understand the code base there.
We are also transitioning the section elders + key information to be network wide and updated in real time, only when required. This allows us to constantly and consistently update information in a secure manner that does not require synchronisation or strict order and in addition allows the network to self-heal as opposed to fail if a single important message fails to be delivered and acted on. This process should see significant speed increases in the Routing layer as well as again removing a need for strict consensused order and instead rely on cryptographic proofs of agreement in real time. It’s a very slick approach that is simpler code but will give us faster and more secure message handling.
As mentioned at the start of the update, Nikita has been working hard to finish the implementation of UPnP in quic-p2p over the last few weeks, and signed out with this PR, which is under review. UPnP gives us automatic port forwarding, which means that the process of connecting vaults from different homes into a single section becomes much simpler and therefore feasible. After reviews are completed, we will begin internal testing, and all going well it’s then over to the community.
BLS - Distributed Key Generation
This week a major refactoring PR has been merged to greatly improve the BLS-DKG crate. It presents a more precise interface to use, and makes the implemented DKG generation flow follow the DKG Protocol paper more accurately. The initial work of introducing quic-p2p as the transport layer has been raised and is currently in progress. Once this is merged, the crate will need to be put through rigorous testing to check how the transport layer usage needs to be tuned and configured in such a way it supports real-world Routing like simulations. Nodes being dropped or delays in messages reaching their destination due to churn events are just some of the real-world network problems that we need to simulate and take into consideration when designing the DKG flow. We are in the process of writing such happy/unhappy path simulations to be tested on a DKG session before we can confidently have this crate employed in the network.
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
Best of luck with your new venture 
