Summary
Here are some of the main things to highlight this week:
- Testing of the cross platform safe-network-launch-tool is well underway.
- In preparation for the first Phase-2 testnet, we’ve started adding a new set of subcommands to the CLI to allow users to install safe_vault on their system (
$ safe vault install) and also to be able to launch a local single-section network with a simple command (e.g.$ safe vault run-baby-fleming). - We’ve been discussing CORS and its place on the SAFE Network over on the Dev Forum.
Vaults Phase 2
Some minor but needed improvements are being made around the options for vault logging. We’ve been working on a couple of PRs to provide the user with options to send logs to files.
As mentioned last week, we started creating a simple tool which will make launching a local (single-section) test network very easy. We’ve made good progress and we are now performing some tests on all platforms and trying to add some simple user guide documentation.
SAFE API
Since the announcement of the Rust v1.39 release introducing async/await expressions, we’ve been working in parallel and with low priority on trying to migrate the safe-authd codebase to the new async/await style. This week we were able to finalise that work in our safe-authd and jsonrpc-quic crates, translating all logic where Futures were being used with simple async expressions. This, as expected, has simplified the codebase of these two crates massively, and allowed us to also start making a better separation of concerns between the jsonrpc-quic and safe-authd crates. This also allowed us to update the quinn dependency to its latest version (v0.5) which already exposes its API with async functions.
We will continue with this migration now on the safe-api crate itself, again as a low priority task and in parallel to the other tasks we are working on, to eventually be able to have async APIs in Rust and in the Node.js bindings with Promises.
In preparation for the first Phase-2 testnet, we’ve also started adding a new set of subcommands to the CLI, this time not only to allow users to install safe_vault on their system, but also to be able to launch a local single-section network with a simple command.
We’ve been able to create a first draft implementation and we are testing it on all platforms. Even though it’s already functional we are making some enhancements to ensure the UX is as good as possible. Just to give a glimpse of what we are aiming at, to launch a local single-section network with the CLI, first safe_vault would need to be installed in your system with $ safe vault install, followed by a second command to launch the local network, e.g.:
$ safe vault run-baby-fleming
Storing vaults' generated data at ~/.safe/vault/baby-fleming-vaults
Launching local SAFE network...
Launching with vault executable from: ~/.safe/vault/safe_vault
Network size: 8 vaults
Launching genesis vault (#1)...
Genesis vault contact info: ["127.0.0.1:44794"]
Launching vault #2...
Launching vault #3...
Launching vault #4...
Launching vault #5...
Launching vault #6...
Launching vault #7...
Launching vault #8...
Done!
Labelled Data, Indexing and Token Authorisation
The last week has seen steady token progress. With our updated Token structs and caveat verification getting implemented in vault mock tests and finalising another PR updating our AppKey storage from the authenticator, to store AuthTokens too. This means we’ll now be able to reissue tokens from the authenticator, without having to ping the user again.
As we finish off these last reviews and milestone, we’re also starting to look more deeply at the next steps towards labels. So we’ve started some planning on what aspects to tackle next, and will likely be updating a labels RFC shortly with information on that, before we start firing in there.
SAFE Browser (desktop)
On the back of some work the community developers have been doing, we’ve been discussing CORS and its place on the SAFE Network over on the Dev Forum. With that in mind, we’ll soon be working up a new SAFE Browser alpha with updated dependencies and permissive CORS, which should hopefully make it easier for web devs to get going on the SAFE Network 
SAFE Browser (mobile)
Last week we released a new version of the SAFE mobile browser which provides the pWeb experience on mobile. Since the release, we have been closely following the forum release thread and looking into the issues reported by the community.
We migrated all the issues from the thread to Browser GitHub issues so they can be tracked and tackled.
We’ve already fixed and closed some of the issues from the list, including the address bar safe label animation freezing on iOS, and an authentication issue which was prompting the user to allow the Browser app multiple times before it eventually returned to the authenticated Browser and let the user continue. Investigation into other reported issues continues.
SAFE Authenticator (mobile)
As mentioned in the SAFE Browser (mobile) section, we have been closely following the forum release thread and looking into the issues reported by the community regarding the SAFE Authenticator (mobile).
We migrated all the Authenticator issues from the thread to Authenticator GitHub issues so they can be tracked and tackled.
A common theme from the feedback was that the user interaction on the vault selection page was not quite as intuitive as it should have been, so we spent some time discussing, developing and trying different UI solutions to improve. An update has now been merged upstream and you can have a look at the new page design in this PR. We also fixed a couple of other reported issues including one issue related to the mobile device’s dark theme overriding the apps own settings on iOS and therefore making some screens unreadable, and we enabled scrolling on the Login page to cover for smaller screen devices having the login button hidden by the on-screen keyboard. We will continue investigating the other issues reported.
The feedback received for the mobile Browser and Authenticator has been invaluable and we would like to thank everyone who took time from their own busy schedules to help determine how we continue to shape these apps, and the SAFE Network 
SAFE App C#
To keep the mobile apps and packages progress in sync with the CLI and desktop apps, we have already started to test the APIs to work with a single section network. We faced some issues related to the native libs generation for the mobile devices when different repos (safe-api & safe_client_libs) were updated to use the new Rust crate versions. With the help of the SCL team, we were able to figure out the issues and we are back on track.
Based on the testing so far, we believe there won’t be too many changes in the APIs before we will be in a position to release the updated packages and apps alongside the new native libs.
Safecoin / Farming
This week, we built on the signed orswot proof-of-concept discussed last week by forking the rust-crdt crate to integrate signatures more deeply into the data structure itself. Some challenges remain, but it seems a step in the right direction.
Routing and quic-p2p
We’re continuing to make significant improvements to our networking library, quic-p2p. The first thing we’re looking to address is IGD support. IGD (Internet Gateway Device protocol) is used for UPnP in home routers; it allows users to automatically enable port forwarding for applications that need it, such as VoIP, game servers, and – of course – peer-to-peer networks. And as the Crust test results have shown, there’s a surprisingly large number of home routers supporting this protocol and it really helps to simplify home vault setup. We previously had IGD support in Crust and so we are looking to port this implementation over to quic-p2p.
Another important thing for quic-p2p is the echo service support. Every vault has a built-in echo server that allows clients to find their public IP address, which is an important step for joining the network. However, the current quic-p2p client code has a limitation: it uses only one address from the list of contacts to send such a request. In the case where that address is unresponsive (e.g., due to a vault being offline), the query would fail. What we want instead is something similar to the bootstrap process: query all of our contacts all at once asynchronously. This way we would achieve much more robust results and better performance.
@lionel.faber is also working to make sure the networking works well on mobile devices. He sent a patch upstream to quinn, the Rust QUIC protocol library, to fix problems he’s found on iOS-based devices.
On top of that, we’re also looking to simplify the quic-p2p API for developers using the library. All of these changes should go into the next release which we are preparing now.
On the Routing side, we are continuing work to improve gossip - which is the mechanism by which nodes exchange messages in order to reach consensus. As mentioned in the previous dev update, we removed the artificial delay which was slowing the gossip down. This means we can now reach consensus faster, but we are facing a new issue - we now create too many gossip messages and they can quickly flood the network. We are currently working on solving this problem.
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 
Now read
-fleming
