Here are some of the main things to highlight this week:
Another week has flown by so it must be time for another quick update from the Marketing Team. It’s been a busy week out-and-about for various folks. Today @ dirvine’s been discussing the future of the internet to a sold-out Digital Scotland 2019 conference whilst @ ustulation and @ nbaksalyar presented at the SAFE Network Brighton meetup last Thursday. The guys discussed the upcoming changes in the SAFE Network backend and the interoperability with Solid. There were some particularly insightful questions from the audience about the implications of Perpetual Data and the effects of storing data forever on the Network, and it was a delight to have these conversations with people of such diverse backgrounds. You can follow the Meetup page for news about more upcoming events - and thanks again to Johnathan and team for their work in putting this on.
We also put out a new SAFE Buzz interview with @ bart at the end of last week - you can check that out here. Next up, a quick word on exchanges. We’re in the process of adding Bittrex International onto the safenetwork.tech website currently (and of course removing Cryptopia).
Final reminder: @ Sotros25 is running the SAFE Network: Chicago meetup tonight in association with the Chicago Blockchain Project (details here). Lastly, @ dugcampbell will be heading down to the Web3 stream of the CogX Conference in London in a couple of weeks - so give us a shout if you're also heading along!
Last week we shared the very first draft of a high level document for a SAFE CLI, which would allow users to deal with all kinds of operations on the SAFE Network. We have also started planning for the development of a first PoC version and have already commenced development over the last few days, you can see our first steps in this public repository: https://github.com/maidsafe/safe-cli.
We also created the current CLI dev plan as a project board in the same repository. As you can see, we are trying to get the $ safe keys and $ safe wallet commands implemented first, which will form the very first PoC release of the CLI. The approach we took, to be able to have our automated tests created before the safe_client_libs APIs are available, is to have a little mock implementation of how we imagine those APIs will be and we base the CLI API and UI development on top of it allowing us to even have our unit tests created.
On the SAFE Browser side, we continue fixing some high priority issues and working on some functional enhancements for our next release. For those interested in more details, you can always look at our SAFE Browser project board, where you will be able to view the issues/tasks we are treating as high priority. At the moment we are focusing on some internal enhancements around tabs managements implementation to solve several issues we've been experiencing.
We are moving full steam ahead with the development of Proof of Concept implementation of 3 recently published RFCs: new data types (AppendOnlyData and unsequenced MutableData), unpublished Immutable Data, and Safecoin.
We are leveraging the existing mock Vault implementation in SAFE Client Libs to quickly iterate on the design: having concrete APIs and simple test apps helps us to hone the RFCs before the final comment period and it will allow us to move quicker with the real implementation of these RFCs in Vaults. We already found some possible points for improvement: GetKey RPC, responses simplification, and Routing simplification.
The new data types and Safecoin affect almost all components of Client Libs, so we keep on estimating and defining the tasks required to be done for this project. You can keep track of the progress on the relevant project boards for new data types and Safecoin.
Because of these changes we've also had to do some routine work to update the dependencies, so we released new minor technical versions of Crust, Self-Encryption, and MaidSafe-Utilities.
Continuing the recent flurry of RFCs, we've been working on drafting an RFC for a Boneh-Lynn-Shacham (BLS) cryptographic scheme that we anticipate will be used in a number of situations. It will both greatly reduce bandwidth overhead and further protect against replay and rogue key attacks. It's an exciting component and builds on, among other things, Distributed Key Generation completed by the POA team for HBBFT.
As with previous RFCs we greatly value all the community feedback and it's fantastic to see all the engagement. In particular, the Safecoin RFC has generated a lot of activity and the discussion is still very much ongoing. We would like to thank @ neo, @ happybeing, @ riddim and @ mav to mention only a few, and everyone else for their excellent contributions.
Another community contribution is this pull request by @ d1vyank (on GitHub), much appreciated!
The detailed plan for the Routing teams is being extended to cover how BLS will be used in the chain, and how to implement Reliable Message Delivery (RMD) and Secure Message Delivery (SMD). We still aren't quite ready to share it publically as we focused on covering more topics rather than making the plan more presentable this week; but we will soon be working on presentability and should have something to share in the near future. Also, just a reminder that the two Message Delivery RFCs will remain open for the next 10 days to allow for final comment.
Following the completion of the Safecoin RFC, resources have been reallocated to start working on a Vault Proof of Concept, which is a big step towards handling data in the network.
Node Ageing implementation is progressing nicely with additional PRs in the pipeline and the spec being fleshed out. Work has been done on being more precise about shared state, which includes creating a SharedState type and making sure it's correctly maintained during churn.
Looking ahead a little, soon we plan to start transitioning the routing crate over to use quic-p2p. This is another item that will further simplify Routing.
