Summary
Here are some of the main things to highlight this week:
- We released a new version of the SAFE Browser, bringing some really nice features of the pWeb (the Perpetual Web).
- As part of the Vaults Phase 2 work, we are starting to make the necessary changes to make sure the Vaults have the same view of the data states for all supported network operations.
- In the SAFE CLI repo, a lot of work has been carried out on getting the first set of FFI (Foreign Function Interface) functions for the SAFE APIs ready and functional. The PR which includes the setup to generate the native libs, C# bindings, and covers most of the APIs has been reviewed and merged.
- Work on implementing Node Ageing has started.
Marketing
This is the last dev update of September 
- how exciting! And as usual, weāve got a ton of news for you this week. First up in marketing is the fortnightly newsletter which should have dropped into your inbox this afternoon (UK time). We discuss the rise of cashless societies, what has contributed to such a move and where crypto fits in all this. Weāll publish this on Medium soon as well so you donāt miss out - but why not make sure you are subscribed to the newsletter and youāll get the stories straight to your inbox?!
Weāve also got a surveillance-themed tweetstorm this week so head over to Twitter to check it out. If weāve missed any pressing stories this week then make sure you let us know by popping them in the forum or tag us on Twitter.
Vaults Phase 2
We are continuing to progress through the Phase 2 projects, mainly focusing on two lines of work: mock Routing and restating the Vault operations in terms of achieving consensus.
We covered the mock Routing in last weekās update, but itās only a part of the story. In Phase 1 Vaults, most request handlers are implemented naively: because we donāt need to have consensus in the context of a single Vault, the flow of operations takes some shortcuts that wonāt work with multiple Vaults. Now, we are making the necessary changes to make sure the Vaults have the same view of the data states for all supported network operations. This is a well-understood problem and weāre already past the design stage. The approach weāre taking requires a small number of changes in the Routing API and in the Vault code. Changes are beginning to flow in with PR#852 which lays in the basic structure for handling consensus and PR#854 where deletion, transfer coins and LoginPacket requests are made to go through the consensus algorithm.
With PR#1034 good to get merged, AppPermissions are all set to be optimized and revamped (explained here in the SCL section) in the mock vault inside the SAFE Client Libs. Corresponding changes are underway in the real vaults to adapt them to the new way of handling application permissions.
Within the Routing crate, we got PRs merged tackling when a PARSEC graph pruning should be carried out. The further work of carrying out detailed pruning work is progressed as well.
While we have your attention, it is worth mentioning that the shared Vault (as part of Vaults Phase 1) was restarted earlier this week and so the vault_connection_info.config file has been updated in the GitHub releases for the vault. See the latest Vault release for the new vault_connection_info.config file - if you intend to use the shared vault you should download this to the relevant location for your platform 
SAFE CLI
As you all know, so far weāve created the first set of SAFE API bindings for NodeJS. This means that web apps and the SAFE Browser itself can use the same APIs that are used by the SAFE CLI. But over the last couple of weeks (and especially during the last few days), a lot of work has been carried out on getting the first set of FFI (Foreign Function Interface) functions for the SAFE APIs ready and functional. This now allows us to start work on creating the SAFE API bindings for C# language (and eventually for Java and other languages). This means the APIs will also be usable by the mobile browser.
Weāve also built some automated tests for the NodeJS bindings (with Jest), which ensure that the data is stored and retrieved correctly when using each of the SAFE APIs. Since all the functionality and logic of the APIs is found at the Rust layer and many scenarios are tested at that level, the tests on the NodeJS binding, as well as in any other bindings, become simpler. They simply make sure that data is correctly transformed back and forth through the binding layer.
We are now considering a bit of refactoring and restructuring in the repo, since we now have three crates to manage: 1) the safe-api exposing the Rust SAFE API, 2) the safe-cli containing the SAFE CLI app source code and depending on safe-api, and 3) the safe-api-ffi which is the layer containing all the FFI functions totally isolated/decoupled from the rest, and obviously depending on safe-api. Therefore weāll keep working on this over the next few days to finalise some reorganisation weāve already done.
Lastly, in parallel we continued with trying to fix some minor issues and adding a new feature which is to allow selecting a specific spendable balance from a Wallet for any of the supported operations. So far all wallet commands would use the default spendable balance as the source/target for any operation made on Wallets. Now weāre trying to allow users to give the friendly name of the spendable balance in the URL so the command can act on it instead of the default spendable balance. E.g., if we have a spendable balance with name to-pay-beers on a Wallet which URL is safe://mywallet, we would now be able to check its balance with:
$ safe wallet balance safe://mywallet/to-pay-beers
SAFE Desktop Browser
Today we release a new version of the SAFE Browser! Weāre introducing some really nice features of the pWeb (the Perpetual Web), allowing users to not only view SAFE sites and their older versions but also to register NRS names (the SAFE Name Resolution System) right from the browser. Users can also now upload and edit their sites (from within the browser).
At this point in time, we havenāt put much effort in the UI/styling of these features. Weāre just making them available with basic functionality so you can taste the future of the Internet already right here, right now!
So go ahead and download it from our GitHub releases page, and start playing around with these nice new features. Remember youāll need to have the safe_auth CLI running and logged in to either the shared vault or a local vault you may be running.
Just to give you an idea of the things youāll be able to do with this new version, here are some high-level descriptions:
- Fetch websites using NRS-URLs and XOR-URLs, browsing back and forth in their version history seeing the websites in each of their versions
- If you try to fetch a website using an NRS name which hasnāt yet been registered, you will be offered the chance to create and register that NRS name with your account! For those who know how current Internet DNS registration works this is interesting to experience
- If you are visiting a website you own, you can edit it right there in the Browser by selecting a local folder (only a folder can be selected in this version) where you want to upload the new website files from. The browser will take care of uploading it and republishing it in your NRS name and URL.
- Websites can alternatively be uploaded and published on an NRS name using the SAFE CLI. Once thatās published they can be fetched either with the CLI or with the SAFE Browser (although note itās not possible yet to edit a website using the Browser which was uploaded with the CLI, neither the other way around, a limitation we will be working on soon in relation to supporting sharing permissions among apps).
If you create a site on the shared vault then why not share the NRS or XOR URL in the thread for others to see!
Just a reminder for those who havenāt been testing our last releases, please keep in mind this is not compatible or usable with the Alpha 2 test network, but only for the new shared and local vaults as explained in this post.
SAFE Mobile Browser
This week we finished the automated UI testing setup for the SAFE mobile browser. To validate the test setup, we added UI tests for some scenarios to test bottom navigation buttons, toggling app theme, opening FAQ page, etc. These tests show that automated UI testing is feasible and is easy to implement. However, work on the mobile browser has been paused for now due to ongoing work in safe_app_csharp which is our prime focus right now.
SAFE App C#
This week we continued to expose more bindings for the new APIs and covered lots of use cases. The PR which includes the setup to generate the native libs, C# bindings, and covers most of the APIs has been reviewed and merged. We still have to refactor and improve the code to make it production-ready.
Once finished, the bindings will help us to provide the simple and clean API for C# and many other languages.
In parallel, we added new issues into our GitHub repo for all the new APIs which we are going to work on next. This will help the team to track the work progress. Also, we have already started to consume the bindings to provide the C# API for mobile and desktop development.
Node Ageing
Some have already spotted this, but we have started implementing Node Ageing 
We have chosen to kick this off with a small focused team right now (think Delta Force, just tougher ). This work involves the introduction of the Adult and Infant personas as well as solidifying the Elder status. It reduces the bootstrap and join process to a much simpler mechanism and allows us to remove candidate and resource proving.
Weāve scoped the initial tasks into the board, and will expand further onto other tasks as we move into a deeper implementation phase.
Node ageing allows us to begin to realise the significance of Sybil resistance proper and make use of those benefits, particularly as now we have PARSEC in play. BLS is happening in parallel and will help tremendously.
In short, this is a big push by the backend team and they are showing great skill and commitment to this aggressive timescale and workload.
BLS
As weāve redirected some staff to kick off node ageing, BLS will slow down ever so slightly, but the implementation for DKG (Distributed Key Generation) continues to progress and we merged the work using PARSEC to collect signature shares for the SectionInfo.
As the node ageing bootstrap/join piece of work completes, BLS will be able to resume at full speed.
Useful Links
Feel free to send us translations of this Dev Update and weāll list them here:
.