Summary
Here are some of the main things to highlight this week:
- We started integrating the SAFE CLI PoC we shared last week (which was made using a tiny SCL-mock) with the actual SAFE Client Libs APIs for all the operations related to Wallet commands.
- We got started on a new SAFE CLI milestone that involves taking the first steps towards supporting the same functionality that the Web Hosting Manager application has for uploading websites in the CLI.
- We merged a large PR which made a massive dent into the task of integrating quic-p2p into Routing.
- Most of the tasks related to Reliable Message Delivery have been completed.
Marketing
Let’s start off with speaking about the fantastic evening the team spent at the Scottish Blockchain event last night. Not only was there mountains of pizza and plenty of beer flowing (supplied by us :thumbsup:), we handed out SAFE Network stickers while @ dugcampbell gave a whirlwind introduction to the Network to a crowded lecture theatre at Napier University, headlined by Andreas M. Antonopoulos. It was genuinely lovely speaking to many of you and hopefully see you at the next get together.
It was a big week for crypto with much of the chatter last night about Libra. In fact, it was a core component of Andreas' talk. You can find out what we think about it over on Twitter but as always, we’d love to hear your thoughts. And finally, we want to highlight the two new SAFE Ambassadors selected by the community - @ Sotros25 and @ oetyng - who as always, are incredibly dedicated and passionate about the cause and demonstrating this through a variety of meetups. If they’ve inspired you, why not set up your own meetup?
SAFE CLI
Active project plans:
As most of you may remember, last week we shared for the very first time a SAFE CLI PoC which supports commands for authorisation of the CLI app against the auth_cli and all basic operations for test safecoins and wallets in general. This first step was made using a tiny SCL-mock (mocking up the safe_client_libs API) implemented in the CLI app itself which allows us to move forward with CLI development in parallel to the SCL development. As can be seen in the Wallet command project plan, we were able to progress with integrating this functionality with SCL APIs for Sequenced MutableData and we still need to finalise the same type of integration for the Key's commands.
This week, we made a small refactor to the CLI files structure which was needed before we grow our CLI API with additional functions. This was the first step completed as part of our new milestone which is to implement the first set of commands that would allow users to upload files (with the files put and files sync commands) and folders on the network and be able to fetch them (cat command) using their XOR-URLs. You can check the progress of this new milestone in this other project board. The main goal of this milestone is to take the first steps towards supporting the same functionality that the Web Hosting Manager application has for uploading websites in the CLI. The plan here is to use Published AppendOnlyData and Published ImmutableData for storing the folders and files on the network, without going into having a proper RDF data representation at this stage yet.
Finally, we made a PR with some usability improvements to the wallet API. Enabling automatic balance creation with new wallets, and simplifying the insert command, which now must take an existing key as an argument (with create doing auto key generation if required).
Mock interface
We are continuing to refine the mock API in SAFE Client Libs and preparing it for integration with the SAFE CLI. We have been focusing on catching up with the changes in the APIs expected by Vaults and removing the legacy code in SAFE Core.
We are also starting to plan the further work that will let us switch the Authenticator so that it can use the new data types and to integrate SAFE Client Libs with quic-p2p (so that it can connect with the Vaults directly). This would require some effort, but ultimately it also should make our code base simpler and improve usability and clarity of our APIs.
Vaults
This week saw the general structure put in place, and hooking it up to quic-p2p for communication with clients. This has required close collaboration with client libraries to make sure that the common datatypes in safe-nd are fit-for-purpose. Work is progressing on the ChunkStore (the data storage layer) as well as correctly initialising all components. With these in place, we hope to be able to start implementing the various batches of RPCs and handlers as listed in the above project plan.
SAFE Browser
Some final fixes for edge cases around experimental APIs and the context menu have been merged into the dev branch. And now we've passed everything over to QA for internal testing ahead of the next release.
Integration of quic-p2p into Routing
Thanks to @ adam's hard work, the progress in quic-p2p integration was really good this week. We merged a large PR which made a massive dent in the task by replacing Crust with quic-p2p throughout Routing. As shown in the project plan, the task as a whole isn't over yet as this opens opportunities for code simplification that we will be jumping on immediately. But it was the largest part and we are really happy to have reached this point :smile:
Reliable Message Delivery
Most tasks here are completed. Many of them were addressed in one pull request that we've been refining over the last week. It was a large piece of work and interacted with recent progress on quic-p2p integration, so we took our time to ensure that all soak tests passed before moving forward with it. And...it was merged today :tada:. Another PR to modify the way we accumulate signatures and lay the ground for Secure Message Delivery is still in progress.
BLS cryptography
We made a start on the BLS front by merging two PRs into PARSEC. Combined, these PRs allow triggering a Distributed Key Generation mechanism and obtaining the key shares as an output. The reason these changes are done in PARSEC is because the DKG algorithm we are using requires ordering, which PARSEC provides. The main user of this code in the scope of Fleming will be the Routing crate. We have yet to publish a project plan for this part of the work but will do this once the final comment period for the RFC is over in a week or so. Note that this DKG code will also have the potential to be used for implementation of a common coin in PARSEC (although this isn't currently a priority).