Hi All,
As mentioned in last week’s update an additional week was required to retrofit an event based channel in routing as the main communication mechanism with the upper layers, safe_vault and safe_client. Between us, anyone working on other parts of the system were probably relieved to get a bit of breathing space, allowing time to better integrate and test their work, so we shouldn’t treat the routing guys too harshly over the delay,… that being said, feel free to interpret that as a royal we. The positive is that the routing API has converged to a point where consensus has been reached allowing us to tick it off as finalised. With the API settled, and some of the responsibility for network security transferred to higher libraries, work on safe_vault and safe_client can now continue unabated.
The relevant changes, published a few days ago, are accessible from crates.io. The remaining tasks for routing during this sprint involve the completion of the implementation with respect to those changes.
Compression has been introduced in self encryption to enable more efficient use of storage space, coupled with a potential reduction in cost on a per chunk basis. A proposal has also been put forward in an RFC to increase file size handling to a temporary maximum of 1Gb using memory maps. Unrestricted file sizes will be the next logical improvement after that, intended to form a significant part of a future sprint. On a related point, the sodiumoxide crate has been updated, including some PR’s from our own fork of the library, allowing us to revert to using that as an independently maintained library in our projects. Thanks to the maintainer for merging those PR’s, it frees us from repetitive application of boilerplate to meet our requirements.
Crust is coming along nicely with the integration of rust-utp, in time this will enable the community to contribute to the network with their own vaults. Completion and running of the tests is all that remains to be done here. Hole-punching is still being actively pursued, initially as a POC example, with proper integration with crust coming after that challenge reaches fruition.
A lot of recent effort has gone into enabling Musl with Rust. Realisation of this goal will give us dependency free binaries, on Linux based systems, to package into the installers. In brief, what that means is, any code linked to a binary as well as between libraries will be done statically. By implication, once installed, the binary runs as a self contained process, thus removing the requirement to package additional files or apply manual updates to your system. The main benefit to be gained from this is a single installer that caters to the various flavours of Linux, Ubuntu, Fedora, etc., over a variety of hardware architectures x86, x64, AMD, Intel, etc. There’s a Musl Wikipedia article for those who may be interested.
Achieving this goal is proving to be less straightforward than one might expect though, and as last week’s update hinted, we’ll have to see how this pans out during the rest of this week. In either case, work has continued on preparing the installers for the currently supported systems scheduled for release at end of the sprint. Again, as a reminder from last week’s update, the packaged installer will include the safe_vault binary, and will be accompanied by the examples bundle, providing ample opportunity to give the network it’s first serious workout.
A weekly QA catchup has now been penciled in, with artistic license, for Friday afternoons, the first having taken place last week. The intention is for the QA team to provide status reports to maintainers covering all aspects of agreed policy. This will allow us to: provide standardisation throughout the codebase, ensure issues and PR’s are being properly addressed and in a timely fashion, make regression free examples available across the libraries and insist that the all the t’s are crossed and the i’s dotted… With everyone, QA, community, developers, you involved, we should observe best practice across the board. Testing is an area to receive particular attention in the early phases with a matrix covering supported compiler releases, similar to that already included in the memory map fork, release mode only testing at the CI’s, and the inclusion of ARM CI facilities and testing.
As promised last week, work has continued on the desktop app, including drag-n-drop capabilities, showcasing safe_dns with authenticated upload to the network. The browser plugin is also shaping up and will be made available to view any uploaded web content. To reiterate, at the moment this acts in conjunction with the mocked routing the guys have been using to test their code. Collaboration amongst the developers has contributed to keeping the mock API in tight conformity with the actual API so the transition to using a full routing network should be seamless.
For the technically minded, development of the desktop app required writing the ffi bindings, an example of which can be found here, to a c language interface that’s exposed to SWIG. The plugin will use js-ctypes to call back into the c interface for content recovery. Pretty simple really.
Now for a demo, in the following screenshot you can see at the start where Firefox is being run followed by a few network actions getting logged via the plugin.
This one shows safe_nfs lib usage from Python, highlighting that error code propagation is being accurately reflected through the binding layer. Python is not a requirement for the desktop app/browser plugin but the guys decided to give it a quick try over the weekend.
Anyway, enough of the development views of what lies under the covers. The design team have been doing some really nice work on the UI in parallel to this, as a preview the current version will look like,
However, we suspect that most of you will be more excited for the next version which is probably going to look like,
As usual the weekly transcript is available for your perusal.
Regards,
Brian
simply can’t wait to play around and upload and retrieve some data!
