Yesterday, we released Test 12b. The logs confirm that the network is working as expected. We will continue to run it and analyse its performance. In the meantime, the parallel tasks of the updated client APIs have progressed to a point where we can showcase these. This has been a priority for us to enable third-party developers and projects to use the API as soon as we possibly could.
We hope that developers will enjoy this new experience, however the large task of documentation including tutorials and getting started guides are underway but not yet available. We anticipate that once again we will start promoting the Community Engagement Program to assist in documentation, use cases and further enhancements to the core network protocols.
The client binaries can be built locally by following the instructions in the
README from the respective repositories.
It has been a very productive week!
We completed the integration of the FFI bindings for authenticator and also the Node.js API. The safe_app_nodejs API seems to be stable with the initial set of test cases now passing. We will continue to expand our test cases in the week to follow and improve the API. Gabriel (@bochaco) was quick to get an understanding of the APIs and he has been contributing to the Node.js API along with Ben (@lightyear). We also added a few minimal examples to the Node.js API to showcase its usage.
@Shankar integrated the
authenticator with the SAFE Browser. We’ve been testing the authenticator using the examples from the Node.js API. The UI for the authenticator will be improved. Also, there is more integration testing to be performed in the following week.
The plugin to handle the
safe: protocol with the new changes has been integrated to the SAFE Browser, which allows browsing of static web pages. DOM APIs are not yet injected for building dynamic web applications.
We are refining the build and installation process of the browser and the Node.js API. Right now, it involves a bit more manual work, but we will be working towards making it easier. We will also wire up an Electron app to allow hosting web content.
The SAFE Browser and the Node.js library currently work against mock routing.
Here are some screenshots of examples running along with the authenticator:
Worth noting that the handling of the IPC response is not part of the CLI example. We will be using the system_uri crate to handle this in the next few days. The authenticator currently prints the authentication response to the console. This is to allow copy-pasting the response in the CLI example.
The Mio-6 bug, which causes failures in Crust and is essential to be resolved before we can port Crust to it fully, seems to have turned out trickier than expected. When we reported random failures on certain scenarios in Crust which we could simulate, Carl, the author of Mio, looked into it and found potential race conditions in the Mio poll function. He plans to rewrite it and is currently on it, resolving this and probably other issues in Mio. In the meantime we continue keeping Crust master to legacy Mio (v5).
Crust has been modified to currently not allow vaults to bootstrap if they fail to be reachable externally. Also, we have disabled NAT traversal just now for peer-peer connections due to too many simultaneous open file descriptors since Routing can now potentially connect to many nodes simultaneously and NAT traversal ends up using more than a couple of socket descriptors per peer to try and punch holes. Since vaults are allowed to bootstrap only if directly reachable, this is OK for now as peer-to-peer connections can reuse that same direct reachability.
Some of the user facing logs have also been improved in Crust.
We also continued refining our longer-term plans regarding data chains and are making steady progress working through the missing details to take it to the implementation phase.