Summary
Here are some of the main things to highlight this week:
- We are just about ready to release v0.0.4 of the SAFE Network App. The major change is the addition of app updates, which means we can update apps such as the SAFE Browser through the SAFE Network App itself.
EDIT: SAFE Network App v0.0.4 is now available! - We are also almost ready to release a small browser update which fixes a couple more pWeb resolution issues, some SAFE Network App interaction changes and enables background updates to be triggered from the SAFE Network App itself.
EDIT: The browser update is now available too. - The first RC version of the MaidSafe.SafeApp NuGet package is now available
Staff
We were delighted this week to be able to secure Qi Maās role as an Engineer in the team. Qi has been around for a great deal of the journey and he is delighted to be around all the way to launch. As we are moving forward we do intend that there will be more additions to the team when it is feasible and prudent. Qi will be continuing in the backend and expect to see a lot more of him as safecoin farming comes into play.
Vaults Phase 2
We are continuing to make some good progress with the multi-vault tests. This week, we have been designing and implementing a new RPC (Remote Procedure Call) mechanism in Vaults to support connection information requests. This is one of the important steps to allow clients to bootstrap to the network without prior knowledge of IP addresses and public keys of all nodes within their section. It should be sufficient to know the connection info of at least one node in the network, which can be used to discover other nodes managing a particular client. Having this mechanism in place would also be very helpful for connecting to the multi-section network (Phase 2b). We have added the prerequisite API to Routing.
Apart from that, we are continuing to improve the Vault testing framework. We discussed and designed a way to improve it by removing some duplicate code, and, more importantly, by utilising mock PARSEC for testing. This would allow us to automate Vault tests without relying on the ārealā network infrastructure: in certain contexts itās more valuable to test Vaults & Routing integration in isolation, taking the network side effects out of the equation. With that, we should have 3 testing modes for different contexts and scenarios: real network (with real clients), mock PARSEC (Vault with real Routing, but with a simulated network), and mock Routing (Vaults with simulated Routing).
SAFE API
Given last weekās new release of Rust (1.39), we already started migrating safe-api to have those APIs which are asynchronous (e.g. those which need to communicate with the network) be exposed as async functions. We were able to already do this in the APIs and also make adjustments to safe-cli to await when calling these async functions. We still have to make the corresponding adjustments in the safe-ffi layer, as well as in the implementation of safe-api where we call the safe_client_libs APIs. We see some minor challenges there but overall this process has been going smoothly so far. Once we have this complete, we are aiming at being able to have the corresponding Node.js bindings APIs return Promises.
A couple of additional features were added to the safe-cli authenticator commands. When using the CLI to either create an account, or log in using an existing one, the account credentials are being prompted to the user, thus we added the same functionality that the safe_auth CLI used to have making it possible to provide the account creation/login details via environment variables (SAFE_AUTH_PASSPHRASE and SAFE_AUTH_PASSWORD) or through a config file with --config <filepath> argument. This is still in progress as we are trying to also adapt our safe-cli integration tests in CI to run against the safe-authd all in the same PR.
In addition to that, the auth login subcommand now accepts a --self-auth flag which allows the user to automatically self-authorise the CLI application on the account that is being logged in with. We believed this was necessary in this particular case, now that we have the SAFE Authenticator daemon, if the user is using only the CLI and no other Authenticator UI, the user would otherwise need to open a second console to authorise the CLI from, which makes it not only confusing but impractical.
Finally, we started adding more documentation to the safe-api repo, trying to detail the main purpose of each of the crates it contains. We started already by creating a top-level README which provides a high-level overview and acts as an index to the other crates. This is still in progress but you can already look at the progress weāve made with the top-level README. We added a couple of diagrams which we hope will be helpful to understand how each of these components fit together.
SAFE Client Libs
Last week we announced the introduction of named containers. Weāve been chipping away at this and we now have the initial implementation in place as part of this pull request. After some review, we will be passing this on to the teams working on the language API and CLI to see if it satisfies the requirements. Weāve also wrapped up the deprecation of the maidsafe_utilities dependency.
We received some useful thoughts about the refactoring of the account containers. Although we are aiming for a basic feature set for the initial release, thoughts and ideas are well appreciated so donāt hesitate to shoot them across on GitHub or on the forums.
SAFE Network App (desktop)
This week weāre all but ready to release an update to the SAFE Network App which enables update management for its applications. So you can easily see what applications are in need of an update, and opt to install those updates ahead of time via the SAFE Network App.
Itās a small feature, but itās involved a lot of testing and tweaking to get this working across platforms. Weāre waiting on one last piece of the deploy puzzle (more notarization fun) before we can hit the big āDEPLOYā button on @StephenCās desk. But once we do, weāll post an announcement here on the forum, or the SAFE Network App should offer you an update notification if you already have the application running.
Once you do that, you should hopefully see an update is available for the SAFE Browser too (if you have v0.15.2 installed via the SAFE Network App prior) as we intend to release an updated version of that at the same time (see SAFE Browser section below!).
With this just about done, weāll soon be now fully focussing on the authentication functionality. With working initial versions on the go, weāre improving the aesthetics and our testing and CI setup.
EDIT: SAFE Network App v0.0.4 is now available!
Note that if you are using v0.15.2 of the SAFE Browser you will NOT be able to update via the SAFE Network App. Youāll either need to uninstall / install via the SAFE Network App, or use the SAFE Browserās baked in updater. Attempting to update via the SAFE Network App will fail as v0.15.2 isnāt capable of background updates.
SAFE Browser (desktop)
A small browser update is coming, just after our deploy pipeline is fixed (see above). This update fixes a couple more pWeb resolution issues, some SAFE Network App interaction changes and enables background updates to be triggered from the SAFE Network App itself. If you already have this installed, on release you would be able to try updating from the SAFE Network App, to get a taste of how application management could work in the future!
Otherwise, weāve been further looking to streamline deployments, builds, and how we can more frequently release the browser, and other desktop applications to folks. Weāre settling on using release channels, so this should be making its way into the browser in the near future. Weāll have an alpha channel for in-house testing (or for those who want to live on the cutting/probably-broken edge), a beta channel, where we can release more stable code for those out there who want early access and donāt mind filing issues / helping debug, and then a latest (stable) channel. This should make updates smoother and more frequent for the community, while also heavily streamlining how we go about testing releases/updates and the applications themselves. We hope this upcoming move will also encourage even more community involvement.
EDIT: SAFE Browser v0.15.3 is now available!
Note that if you are using v0.15.2 of the SAFE Browser you will NOT be able to update via the SAFE Network App. Youāll either need to uninstall / install via the SAFE Network App, or use the SAFE Browserās baked in updater. Attempting to update via the SAFE Network App will fail as v0.15.2 isnāt capable of background updates.
SAFE App C#
We are really excited to announce that the first RC version of the MaidSafe.SafeApp NuGet package is now available . The package exposes all the new APIs available in safe-api and you can use it to perform any operations on the SAFE Network possible using safe-cli.
Itāll be wonderful to see what you develop using this updated package. If you find any issue please raise an issue on GitHub and if you need any help with the APIs/app development using C#, please start a thread on the Dev Forum and ping @ravinderjangra.
We have also updated the safe_app_csharp README file to reflect the updated supported desktop and mobile platform versions.
In parallel, we are trying to expand our build and test setup to run the tests against a local running vault. This will help us to validate the proper working of production libraries on all the platforms.
Node Ageing
The week we had a very large and complex PR merged that deals with triggering relocation based on churn events as well as fixing flaws in the previous relocation logic. This is a significant step towards implementing node ageing and went through intense soak testing to iron out any subtle issues. Investigating soak test failures for some of the more complex cases can be a very time consuming and difficult task so everyone involved in that deserves a beverage of choice this weekend!
Another crucial step in implementing node ageing is elder promotion and demotion. Weāve made some good progress and are in the testing phase. As usual when working with the routing crate and the very async nature of the problems it solves, once things are implemented and you start running real system tests you discover all sorts of corner cases that need handling. So this week saw additional improvements to the testing framework to help us there.
We also merged the next step in the Connection handling simplification with one PR related to tracking connection info for elders merged. There are two more PRs in the pipeline to complete this task, with one of them in the soak test stage and almost ready to be merged as well.
To facilitate integrating with safe_vault, the API was extended to give access to section elders.
Work on PARSEC pruning has been mostly completed and is currently in the merging queue. Handling disconnects via tracking unresponsiveness is now being continued and is expected to resolve the bulk polling issue due to the new testing pattern.
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 that gives us hope I recon and with grit it also gives us options.
