Here are some of the main things to highlight this week:
- RFC 59 has been published today. It describes a proposal to integrate Boneh-Lynn-Shacham cryptographic scheme into Routing.
- safe_client_libs is now actively using Jenkins To read more about Jenkins, why we introduced it and what benefits we believe it will bring us, see this forum post.
- We’ve put out a new edition of SAFE Buzz with @ravinderjangra.
First off, thanks to @Sotros25 for running another SAFE Network: Chicago meetup - check out some of the pictures here! Along with helping the QA guys out with the Jenkins post below, we’ve also put out a new edition of SAFE Buzz with @ravinderjangra, who talks about the journey that led him to discover the SAFE Network.
Today, @dirvine’s been attending the Energy Innovation Emporium 2019 whilst next week, @dugcampbell will be down in London at the Web 3.0 & Decentralised Future stream of the CogX Conference. There’s a great line-up of many of the biggest decentralised projects across the scene and no doubt some fascinating conversations to be had - so if you’re also heading along, please do reach out for a chat. Finally, we’re now also supporting the Scottish Blockchain meetup on Wed June 19th where many of the team will be heading along to hear Andreas M. Antonopoulos talk in Edinburgh.
Some unfortunate news this week. Over the past couple of weeks, we’ve been forced to make a couple of redundancies to reduce the operations and admin headcount in the Ayr HQ with a view to maximising our engineering spend moving forwards. Alas, this has meant that we’ve had to part ways with @dgeddes and @kayley. Both carried out a truly sterling job for us over the past year or so and both were hugely well-liked throughout the team so we’d very much like to publicly thank both of them for all they’ve done and given to the MaidSafe cause during that time. They remain committed SAFE Network advocates and hopefully you’ll see them remain in the community moving forwards. We don’t anticipate any further redundancies at this time.
SAFE API & Apps
This week has seen some investigation into a new issue in the browser build process on Linux, and we’ve uncovered some issues with electron-builder itself. The electron-builder team is taking a look at the issue, so once a fix is merged we’ll update our dependencies there. This came about as part of our testing for Auto Update in the browser (which is otherwise looking good!).
$ safe CLI has continued at full steam during last week. As can be seen in this public project board, we were able to implement several sub-commands for both the
wallet top-level commands. For example, we already have the implementation (against an internal and temporary mocked safe_client_libs API) for generating BLS key-pairs, which are then stored in a
Key on the mocked network. We’re even able to preload a
Key with some test coins, as well as creating a
Wallet and inserting
Keys so they can then be used to make transfers between
Keys. We know it may be a bit confusing now, but we are planning to start shortly with a user guide which should make all these use cases much clearer and hopefully extremely simple to understand and use.
Right now we are finalising the review and testing of two PRs which would allow CLI users to use XOR-URLs based on CID (choosing
base32z as the base encoding for them), as well as making test coin transfers between wallets and checking their balance.
We are also expecting to be able to remove the temporary mocked safe_client_libs API early next week, and start integrating it with the real APIs exposed by the safe_client_libs crate, using the new data types, which would allow us to start using all the wallet CLI commands on the SCL mock network.
SAFE Client Libs
This week we’re continuing with the work related to the new data types, the mock Safecoin, and some other nice things that come with them (like supporting multiple data owners and multisig through BLS keys). We are seeing some good progress with that and we’ve already implemented some of the functionalities of Unpublished Mutable Data in the mock Vault. We’ve also completed the definition of Append Only Data in safe-nd (the network data types library). Soon we’ll be moving on to FFI functions for Unpublished Mutable Data, Append Only Data, and Unpublished Immutable Data.
However, during this milestone we don’t plan on removing the ‘classic’ Mutable Data, used by the internals of the SAFE Authenticator, for example. However, we will expose the new data types for app devs, but won’t use them internally ourselves at this stage.
This week has seen further work on a few different fronts.
We continued to progress the RFC for making use of BLS keys within the network. This included a presentation of the current state of the RFC-in-making, and as a result of that, some further work has been completed, and the RFC is now published and has a corresponding thread in the forum.
Meanwhile, work to replace Crust with quic-p2p has started in Routing. Currently, we have a PR introducing a mock quic-p2p interface which allows us to test the integration while we complete the full replacement of Crust.
Some of the Routing tasks have been documented in a number of GitHub project boards.
Finally, work is continuing with the Vault proof of concept. This has involved both the vault crate and safe-nd crate, since the vault-level RPCs, the data types, and node identities are being migrated there from Routing. This will ultimately result in being able to break SAFE Client Libs’ dependency on Routing.
We want to announce there will be no updates about quic-p2p in the coming weeks because we don’t anticipate any more effort (apart from the maintenance work) going into this project before the network launch. This will enable us to shift our resources into the other libraries to make them launch ready!
This week we have reached a major milestone on the path to using Jenkins to deliver an automated release process for all our deliverables - safe_client_libs is now actively using Jenkins
Jenkins is a leading open source automation server, widely used to enable CI and to help facilitate continuous and automated delivery. A lot of planning and development time has gone into setting up a robust and secure infrastructure to ensure this setup works for us. It will be used on the safe_client_libs repo from now on, and will gradually be rolled out to other repositories when suitable. Kudos goes to @chriso for a huge effort in making this a reality - we are sure the benefits of this effort will be seen over the coming weeks, months and years.