This week we are continuing to make progress towards our goal of releasing a testnet with Mutable Data support, as explained in last week’s update:
One thing we need to address for the next testnet is clients spamming the network with various requests. Some potential solutions are being discussed in this Dev Forum topic. We haven’t picked specific solutions yet, but it’s likely that spam prevention will initially be a bit more aggressive than we ultimately envisage in the long term. This is because of the small number of Vaults in these testnets and we want to make sure that the network can’t get abused when it’s at its early stages like this.
There are a lot of things that are in progress and dev updates are likely to be short while heading to the next testnet with Mutable Data.
@Shona (the front-end designer who was away for a while) started to work with the front-end team this week, reviewing the UI & UX for SAFE Authenticator and the client apps. So we will once again be working on UI design and thinking about how the user experience as a whole is coming together, which is something we haven’t been focussed on recently.
SAFE Authenticator & API
The API issue with Electron has been resolved and the fix (fix unsafe pointers returned by FFI functions) has been merged in safe_client_libs. With that out of the way, we also had a few minor bugs/enhancements passed to the safe_core team. @nbaksalyar has addressed most of them and we are updating the FFI bindings to support the changes. We hope to do some regression testing using the mock network early next week. Stabilising the authenticator and the apps against the mock network is the priority for the upcoming week.
@Kumar is continuing with JNR vs JNI for Android. JNI involves more work and maintenance, while JNR would ease the work immensely. Hopefully, we will have some results to conclude by next week.
SAFE Client Libs & Crust
Routing and Crust had separate identities with the Routing layer uniquely identifying itself with something called a public ID and Crust by peer ID. This lead to some RPCs giving only part of the information causing a lot of additional bookkeeping. To reduce this maintenance hassle, Crust is now completely templatised to take a unique identifier given some properties it defines via an exposed trait. This PR is ready for review and merge. We might plan and expand this further to make it securely (encrypt and sign) serialise the Crust payload, again by renaming and expanding the scope of the trait, in the future. Also, there are some thoughts on templatising based on the Routing messages too, so that we don’t serialise and deserialise at every crate boundary. This should give some performance benefit and will be taken up in a later phase.
safe_client_libs had some fixes implemented. The Authenticator used to return an Auth-Error if an already authenticated App tried to re-authenticate. However, there are valid cases where this could happen. For example, if an app was authenticated in machine-A and now it was installed in machine-B and tried to get the required Auth-granted packet from the Authenticator, the Authenticator would simply return an Auth-error. So this is now relaxed to always return the expected payload via Auth-Response.
Invitation-based account creation is also being ported to the dev branch in this PR.
Routing & Vault
With PR 1430, we finally have deterministic mock Crust tests: Any failures in the simulated network will now be reproducible on any machine, so that they can be studied in detail and fixes can more easily be verified.
The final part of resource proof has been merged, moving the CPU challenge part to a separate worker thread.
We are looking to derive a node’s name from its public signing key and make Crust use the same key pair as Routing as a peer identifier, to simplify the current implementation as well as the future work on data chains. The first part of this change is almost ready. Currently Routing identifies nodes with a mutable public ID, and Crust uses its own “peer ID” type for the same purpose. Having only a single, immutable identifier will help us make the message flow and several data structures less complex and easier to understand.
And finally we are working on some long-postponed security checks to make sure we never add an entry to the routing table without verifying that the node in question has passed the resource proof and there is a consensus in its section that it joined the network by completing the proper relocation process.
.
