Summary
Here are some of the main things to highlight this week:
- We released SAFE Browser v0.15.1, which fixes some of the version browsing bugs that had been reported on the forum and sets the browser to use the provided mimetype from the new XOR-URLs.
- We published a blog post on the new Perpetual Web browser.
- In Vaults, we merged a PR which adds consensus to requests for data deletion and login packets storage.
- In Routing, we merged a PR that simplifies the bootstrapping process.
Vaults Phase 2
We’re making good progress with the Phase 2 project. We’ve merged the pull request which adds consensus to requests for data deletion and login packets storage, and we’re now moving towards adding consensus for the rest of requests (like coin transfers). We’ll continue to test different scenarios with multiple Vaults configurations - including mock Routing; real Routing with mock PARSEC; and eventually real Routing with real PARSEC (once the library interface is ready).
We’ve also fixed a bug that we found earlier: in storing Vault data in the temp dir, there could have been a risk of data loss caused by certain operating systems (like macOS) pruning that data at a certain interval, deleting the Vault chunks. This has been fixed by switching the default storage location to a local settings directory.
SAFE CLI (Command Line Interface)
We’ve finalised the restructuring of the safe-cli repository with a workspace setup. We now have three folders: safe-api, safe-cli and safe-ffi, which helps us maintain these crates in isolation from each other. This allows us to publish them separately when we have some automation ready, e.g. safe-api will be published on crates.io for any Rust application developer to consume whilst safe-cli will be released in our GitHub releases page (as we’ve been doing so far). And the safe-ffi library and bindings could also be published in our GitHub releases page. There are still some minor things to work on before we can start doing this though, but we are not far away from it.
The safe-ffi crate has been taken to a state where it covers all the currently existing APIs exposed by the safe-api crate. A couple of minor issues were solved in the FFI, including one which was causing the C# bindings tests to fail, so this is good news for the effort we are putting in the development of the C# bindings.
We’ve also finalised the implementation for using specific Wallet’s spendable balances in safe-cli wallet commands/operations as we commented last week, which will be part of the very next release of safe-cli (hopefully soon). We’ve added details about this Wallet feature in the User Guide if you want to learn a bit more about it.
Some research has also started with some good and encouraging initial results about having the Authenticator run as a daemon, and merging all the current safe_auth CLI commands into the $ safe CLI, which we believe will simplify things massively for users since there will be only a single CLI, but we expect this to also simplify maintenance of the code and release process. We are also considering using QUIC for the communication and transport of the authorisation requests and responses (currently being done through HTTP), so we can benefit from several features, like security, provided by this protocol. We are trying to get a first Proof of Concept ready ASAP to be able to share it with the community for testing and feedback.
SAFE Network App
The app has had some cross-platform love during the last week, with several fixes in place for all three of our favourite platforms, aligning them much more closely and making some platforms (cough Windows cough) now useable on some level. So we’re happy to be handing this over to everyone’s favourite QA team now!
SAFE Desktop Browser
This week we released a minor update to the SAFE Browser, fixing some of the version browsing bugs that had been reported on the forum, as well as setting the browser to use the provided mimetype from the new XOR-URLs, which should remove a bunch of content type errors folk were seeing with their sites / image rendering.
Check out the Medium piece on the new Perpetual Web browser that was released earlier today.
We’ve also updated the browser build process to remove some small hacks, which should make things both more reliable and faster, too.
SAFE App C#
We finished the initial setup tasks required to start exposing the new C# API in the safe_app_csharp package last week but while running the unit tests we faced a blocker issue. Because of that we were not able to fetch the data from the vault. With the help of the SCL team, we were able to figure out the root cause of the issue during the weekend and implemented the fix.
Once the issue was fixed and we got a working solution along with some basic tests, we made good progress and successfully added new APIs for keys, wallet and files in safe_app_csharp 
These APIs will enable developers to perform a whole range of different operations (if you think about the range of functionality that’s available via the SAFE CLI, you’ll get a good picture) when it comes to keys, wallet and files. Next week we will target NRS and finish adding tests to the fetch API.
Node Ageing
One overdue change carried out in the last week is that node responsiveness and participation shouldn’t be determined at the network layer using timeouts etc. Instead it should be handled at the routing layer where a node that doesn’t participate in voting should be voted offline. In a fully asynchronous network nodes shouldn’t need to worry about being constantly connected to other nodes, only that they participate at the pace the network requires.
Apart from that, we continue to remove parts of Routing that cease to be useful. As a part of this work, we merged a PR that simplifies the bootstrapping process.
In the old approach, a joining node had to contact a bootstrap node who would serve as a proxy in all communications between the node and the network. The node would then introduce itself, ask for relocation, receive relocation information from the proxy’s section, contact a new section and pass their resource proof challenge, before it was promoted to a full node. This required the network to perform quite a bit of work for every joining node: the initial section would have to reach consensus about where to relocate the node, the target section would have to be informed that they are to expect a new node, and finally the target section’s bandwidth would be used to perform the resource proof.
In the new approach, we aim to offload most of the work onto the joining node. Instead of the Network negotiating where to relocate the node between themselves, the node is being directed by the nodes it contacts to connect to the right section directly. All communication is happening between the joining node and the nodes it connects to. If the section it connected to isn’t the right one, it will receive the Network addresses of some nodes closer to the proper destination. Once it connects to the right section, it will become an Infant or Adult right away. Then the section is free to perform any necessary checks, but that will be an issue for future tasks.
Marketing
Due to various holidays/travel, there are no major updates from the Marketing Team this week - simply business as usual (plus of course the Medium piece on the new Perpetual Web browser that was released earlier today).
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
