Summary
Here are some of the main things to highlight this week:
- @jimcollinson made a video where he talks about the thought process, user research, and testing that has gone into the on-boarding design for the Network.
- We released a new version of the SAFE CLI (v0.5.0).
- We started publishing the
safe-api(SAFE Rust API) on crates.io.
Marketing
Just a wee update from the team this week. We’ve published our regular tweetstorm over on Twitter so go check it out and let us know what you think - it was quite a week in the world of surveillance, privacy and internet shenanigans so an interesting one to curate. We’ve also published the content from the SAFE Gossip newsletter a few weeks back, looking at the rise of cashless societies. You know the drill - head over and clap 50 times please!
But before we go, we’d like to bring to your attention the amazing work by the community’s Bulgarian superstar @Dimitar. His website, which is of course all about SAFE, has been nominated for an award and you can find out all the details here. Things like this are truly humbling and it’s incredible to see how committed this community is every single day.
Vaults Phase 2
This week we have been focussing on working out the details of the Routing interface which is to be used by Vaults. It is straightforward for cases when a Vault calls the Routing library (e.g. when requesting a consensus vote), but we need to be more prudent in cases when Routing needs to pass events & data down to Vaults because we don’t want to expose the Routing internals too much, so as to minimise the knowledge required to use the library. In the end, it is more of a software design challenge: we want to have a minimal and understandable API while still maintaining the ability to test Routing and the network in various configurations (with or without real networking, with mock PARSEC, and so on). We have found some good solutions to these problems and we are getting close to integrating the real Routing with Vaults. The progress can be tracked in the issue #878.
In parallel, we are continuing to work on the consensus voting for client requests. With just a couple of exceptions, all the client requests now go via consensus. This makes the Vault ready to interface with the Routing library, so very exciting times ahead. We’re also working at overcoming some of the limitations in the Phase 1 vault, for example the vault currently does not handle refunds when some data operations fail. With the enhancements in this PR, the vault can identify legitimate errors returned by data handlers and refund the Client that paid for the operation.
SAFE CLI (Command Line Interface)
SAFE CLI v0.5.0 has been released and made available for everyone to upgrade with $ safe update, or it can be downloaded from the GitHub releases page if you didn’t have a previous version of it.
In this new SAFE CLI version, a couple of new features we’ve talked about in previous dev updates were included, e.g. the ability to choose a specific spendable balance from a Wallet for any command, and the new dog command to inspect URLs and their resolution, among other minor enhancements and bug fixes (refer to the changelog for more details).
We also started publishing the safe-api (SAFE Rust API) on crates.io. Yesterday, safe-api v0.5.0 was published, and although we still have to work on the safe-api documentation, it’s already available for Rust applications to use it as a dependency from there.
This allowed us to publish a new version (v0.3.1) of the safe-nodejs package, which is now depending on the latest safe-api v0.5.0 from crates.io. This new version now includes all the Node.js bindings for the SafeKeys and Wallet APIs which were missing in the previous version, and therefore are now ready to be used by Node.js applications.
Our efforts on creating the Authenticator daemon (authd) continued during this last week, with some successful first tests of starting/stopping the daemon, and interacting with its exposed services (through QUIC), all using the new commands in the SAFE CLI. A new authd client API is what we are working on to allow not just the SAFE CLI but any other applications to be able to communicate with the daemon with no need to understand the communication protocol. We therefore already started trying to get some basic Node.js bindings for this new API, towards trying to test it from Electron applications, which will be required to allow the SAFE Network App to communicate with authd.
SAFE Network App
Another video for you all this week, as @jimcollinson takes you through the thought process, user research, and testing that has gone into the on-boarding design for the Network.
How do you create an account without permission from anyone else, and how is it possible without a centralised process, server, or organisation? And how do you do this while maintaining the security and integrity of the Network, and maintaining personal privacy?
We identified numerous approaches as to how this could work, and how you could get started on the network:
- By starting a vault. This is a way of offering resources to the network, and being rewarded with some currency, that you can then use to create an account.
- By paying for an account with fiat currency, via an exchange.
- Through creating an ‘offline’ account packet, and having a friend who is already on the network, upload it, at a cost to them.
- Making an empty offline wallet, sending it to a friend for them to fill up with the required amount, in order for you to create an account from it.
- Creating an offline ‘inactive account’ which would then be activated by a user with some Safecoin.
- Having another user gift you an invite… a special link which they’d purchase, which would contain all you’d require to get going.
- And then, of course not forgetting, there are those of you who already hold MaidSafeCoins, and who will be able to covert some of them to pay for a SAFE Account.
In the video above, Jim talks through how we narrowed these down, and the solutions we’re building first.
We’ve also been continuing on two other fronts:
Updates Project plan
Auth Project plan
On the one hand with the Update project board, as well as other wee tweaks (e.g. using S3 instead of GitHub for downloading resources, as GitHub was proving to be slooooow), and some other internal tweaks to how we manage detecting app version updates.
We’ve also been firing in with experimental auth API integration into the SAFE Network App. Here we can really see the benefit of the new API structure which was born out of safe-cli, with start/stop of the auth daemon, login, logout and create account all getting integrated quickly into the SAFE Network App. We’ll now be smoothing out the rough edges of this implementation, increasing test coverage and, as the APIs stabilise and make it into the safe-api master branch, working towards a release there.
SAFE Desktop Browser
We have a new patch release of the browser to be released soon (pending some final QA). This fixes some pWeb resolution issues, as well as adding in another pWeb (Perpetual Web) requirement of blocking un-versioned resources requested by the DOM from another domain. This means you will not be able to pull CSS from safe://somewhere-else and avoid having to version the website when you change layout/content shown, etc.
It’s important to note, this doesn’t prevent folk from using the DOM APIs to request data, it’s just that the original document/content will be reliably versioned and therefore replicable.
We’ve also bundled some dependency updates and a new version of safe-nodejs into the browser. We’ll be exposing the XorUrlEncoder functionality from the API as some folk have been requesting this.
SAFE App C#
This week we added the inspect API from safe-api which allows the devs to get the metadata for any data stored on the network using its safe:// URL. We also added some tests to ensure this API is returning the correct data from the network.
To keep up with the new API and FFI changes, we have updated the Cake build script to use the latest native library generated from the safe-ffi CI. The script can be used to auto-download the native libs based on a release or a master branch’s commit hash.
We have bumped the minimum supported platform versions in safe_app_csharp. This will help us to use the latest C# language features and provide a more stable API.
In parallel, we are testing the APIs with the local vaults for all supported platforms. During testing, we discovered that the new APIs aren’t able to connect to the local/shared vaults from mobile devices. Currently, we are working on a fix to resolve this issue.
Node Ageing
As you will see we have whittled Node Age down and have 2 smallish tasks left to do there. That allows us to be more focussed on the vault / routing interface and @ustulation & @nbaksalyar have been busy in parallel (with help from @Jean-Philippe) finalising the implementation design there and in fact implementing that, along with addressing some test failures, and progressing detecting unresponsive nodes.
As node age closes, it means we have Sybil resistance in place. This allows nodes from home (no more centralisation), but we will still maintain the phase 2a/b, 3 and 4 stages of the project plan. We don’t want project pipeline confusion, but we do want serious reduction in time to launch. So a lot happening in parallel here in the backend of vaults while the UX of vaults is being progressed by @lionel.faber, @yogesh & @marcin for phase 2a vaults.
This may seem fast and a bit wild, but this is Engineering at its very best. We are pulling it all together here and leaving time to focus on internals (such as replacing emulated BLS with real BLS) while we try out small testnets (possibly all private to begin with) and confirm acceptability.
We have simplified much of the code here and still have a small amount to do, but the end result is simpler (less bugs), more efficient and importantly a much more understandable code-base. We hope this progress allows us all to enjoy running SAFE in the wild sooner than most realise. We will iterate full networks, not individual components and this is a much more effective approach to roll out.
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 apologies for 6-0 in the week. 
