MaidSafe announcement, please read
Summary
Here are some of the main things to highlight this week:
- @JPL updated the SAFE Network Primer.
- We released a new version of the SAFE Browser (v0.15.2).
- We started developing the SAFE Network App for mobile
Marketing
Itās Halloween guys 
And hopefully, youāll find this weekās update devilishly full of treats to get your fangs into.
First up, we have an updated primer! A massive thank you to @JPL who has updated it with the now fully ABFT consensus algorithm PARSEC, ways in which the Network defends itself against common forms of attack, the new AppendOnly data type and the introduction of the quic-p2p routing library which replaces Crust. Absolutely fantastic work by @JPL as always. The primer is a staple marketing tool we use when weāre speaking to people about the Network, or when we just need to refresh our memories about different parts of the network, itās always close by. Itās so good, itās scary 
.
Weāre also almost ready to send out another October Newsletter. Thereās a couple of tweaks to make (and we want to get this out 100% perfect) so this will likely reach your inbox tomorrow, just in time for the witching hour.
And finally on this ghoulish night (ok weāll stop with the Halloween references), it was a pleasure to see some of you switch on to the new season of Silicon Valley. We, of course, acted as advisors on the last season, but weāre sure this season will continue to drive the conversation forward about the need for decentralised networks which is always great news for us.
Vaults Phase 2
We have succeeded in running Vaults with the integrated Routing. There is still some work required to set up proper sections and to make the SAFE Client Libs aware of multiple Vaults, but we are getting the first promising results: the nodes are exchanging messages and voting on events through PARSEC and these results demonstrate that we are getting close to fulfilling the goal of the Phase 2a, that is running multiple real Vaults within a single network section.
With Vault phase 2a nearing its end and the rest of the tasks being sequential, the team now has some time to add a few enhancements and newer APIs to the SAFE Client Libs and thus are temporarily switching to tackle down the new project board aimed towards the next version of SCL. This board will be used to track the upcoming & newer high-level APIs and also issues from SCL met by the CLI team.
SAFE CLI (Command Line Interface)
The development of authd (Authenticator daemon) continued with good pace and we were focused on adding support for Windows. We are very happy that it can now also run as a Windows service. Creating a service on Windows wasnāt that complicated but we did have some minor challenges to face, e.g. Windows needs the service to first be installed before it can be started (as opposed to Linux/macOS where it can be simply launched), so we had to add a couple of additional commands (install/uninstall) to authd which are supported only for Windows now. Windows also requires admin permissions to not only install the service but also to start and stop it, so weāll be adding some Windows-specific details to the User Guide to cover these aspects.
authd keeps track of the authorisation requests received in memory, and it also has the list of the endpoints subscribed to receive notifications for these authorisation requests (e.g. SAFE Network App would be a subscriptor), itās crucial it keeps those lists tidy in order to not allow them to grow indefinitely. Thus we worked on making some enhancements to cope with a few scenarios where auth requests need to time out and automatically be removed from the list, as well as automatically unsubscribe endpoints which became unresponsive when a notification was attempted to be sent. This all helps authd to be more stable and to use a reduced amount of memory and resources.
We are now trying to start with some more sophisticated integration tests, ideally trying to make sure authd works nicely with SAFE CLI, SAFE Network App, SAFE Browser and web apps, and if all works as expected we will be able to share it very soon for you to try it out.
This point seems like a good time to bring QA into the process so they are actively going through the latest authd developments and putting it through its paces.
In addition, @marcin has lately been involved with the Foreign Function Interface portion of this crate, doing code reviews and helping the team with FFI-related questions. This week, he did a small refactor moving FFI-specific code to the FFI module. He has also raised some minor PRs to fix style issues, making the Rust code more idiomatic.
We are also having some design discussions in relation to how to keep evolving the safe-api. We are now looking at ways to expose more APIs that will allow users to manipulate all the data types supported by the Network, i.e. apart from the ImmutableData APIs we are already exposing, we would like to start exposing APIs to directly manipulate published/unpublished AppendOnlyData, and MutableData. We are of course trying to make sure they are as friendly and simple to use as possible, providing nice abstractions for the most common use cases first. Weāll be sharing more details once we have an initial draft of all this.
SAFE Network App (desktop)
The past design sprint has seen our focus turn to Vaults, and more specifically how a Vault can be installed and run easily from the SAFE Network App.
We started first by addressing the onboarding flow for a new user. How can they offer up some of their computerās resources and earn their way to a fresh account?
We looked at several approaches to this initially, but settled on reusing some of the language and journey flows from previous user research, by enabling the user to use a Vault to generate an account inviteāprepackaged to give them all they need to get up and running. This will, of course, need to be tested with real users in due course, but for now we build out the full Vault suite with this as our baseline.
From there, the user can keep the Vault running, earning them Safecoin to fund their day-to-day Network use.
But this onboarding flow is only one small part of the complete Vault UI picture. What is an ostensibly simple program, has various modes of operation, which we need to take into account. So weāre building and considering flows for:
- Allocating hard disk space and storage location
- Starting and stopping the vault
- Seeing the Vaults status, a log of events, and current earnings
- Changing basic settings, such as enabling auto-restarts
- Electing to send earnings to a specific wallet or SafeID
- Starting and operating the Vault while logged out, and then ālinkingā it to your account later, allowing it to be protected, and sweeping funds to the default account wallet.
- How we might allow for monitoring and configuration of Vaults running remotely
Of course weāre putting things together with the core functionality in mind, but weāre still thinking about how we allow for more advanced monitoring and richer statistics in short order.
We aim to make things solid, useable and understandable. We wonāt get there in just one leap, but a series of steps and feedback loops. We look forward to showing you all those pieces coming together very soon.
On the implementation side this week, weāve been syncing with the latest authd changes as described above and have started implementing flows for simply accepting or rejecting authentication requests.
SAFE Network App (mobile)
Weāre really excited 
to announce that the development work for the SAFE Network App Mobile has kicked off, as the C# APIs are available and the NuGet package isnāt too far away.
We have already completed the initial project setup and this week we spent some time to scope out and plan the tasks for the very first version of the SAFE Network App on mobile. We are focusing on the UI design first and have started to work on a couple of screens.
Weāll let you know more details in the coming weeks about how the SAFE Network Mobile App is going to be a game-changer and a one of a kind application on mobile. The design put together by the UI team is really incredible and it is going to be a real joy to develop and use the app.
SAFE Browser (desktop)
This week weāve released a new version of the SAFE Browser (v0.15.2), which updates Perpetual Web resolution logic and finally exposes the XorUrlEncoder. It also updates Electron to v6.1.0 and fixes several bugs. And on macOS, you will notice that the app is now notarized - no more errors when opening on macOS Catalina!
When opening a previous version of the perpetual web browser you will automatically be prompted to update to this latest version, or if you are downloading for the first time, use the link above to the release on GitHub.
Beyond this release, weāve also written some more detailed tests for the new resolution logic and started the path to upgrading to Electron 7. Weāve also been working on some new features to more easily test and check releases without complications arising from the auto-update mechanisms.
SAFE App C#
A lot of work has been going on, over the past couple of months in safe_app_csharp and as you can see in the project board we are very near to the fruits of success (in this case, release ) and along the way we have tackled different problems on different platforms.
For the past couple of weeks, we were having issues with the iOS CI build and test pipeline and we werenāt able to test out APIs on the CI. This week after trying different methods and tools we managed to fix (#159, #162) the issue and now we are successfully running the tests for the new C# APIs on all supported desktop and mobile platforms.
We have also exposed a new API for setting the vault configuration file path that is needed for mobile platforms to connect to the local/shared vault (#158).
This wouldnāt have been possible without @lionel.faber and the SCL team who helped in creating a function for setting the vault configuration file path in SCL (#1051). Using this API, we have finally managed to connect a mobile device to the shared vault. We still have some work left in connecting to a local vault, which we hope will be resolved very soon.
We have also exposed the newly added permissions for apps to access the balance and perform mutations (#156).
Node Ageing
We have been continuing our efforts to enable the relocation mechanism and to implement Elder promotions and demotions.
On that first front, the mechanism itself was implemented last week, now we are working on actually triggering relocations when applicable. This is progressing, but there are still details that need to be polished and worked out.
With the Elder promotions and demotions, we ran into problems with how they are playing with our current way of handling churn. As it turned out, the multi-step process we have in the current code often leads to sections becoming stalled when promotions and demotions are enabled. We are currently working on simplifying this and removing the risk of a section getting stalled when the set of Elders changes.
Additionally, the first part of the work on simplifying connections between Elders is now complete, unblocking the work to handle multiple joining notifications at the same time. This new test also proved useful in uncovering corner cases that we are working on fixing. Finally, we made further progress on tracking whether Elder nodes are still responsive or need to be removed.
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
. The progress this week is amazing, and exciting to see.
