SAFE Network Dev Update - May 23, 2019

Summary

Here are some of the main things to highlight this week:

• RFC 57: Safecoin revised was released earlier this week.
• RFC 58: Reliable Message Delivery was released today. This RFC complements RFC 56 and should complete the big picture for communication of messages across the Network.
• The new data types that were introduced in the RFCs last week (RFC 54 and RFC 55) are being prototyped as a Proof of Concept in mock.
• The front-end team published a SAFE CLI High Level Design Document.
• @nbaksalyar was speaking at the first SOLID meetup in London.

Marketing

This week, Nikita was speaking at the first SOLID meetup in London (check out the video here) whilst this evening sees the next edition of the SAFE Network: Brighton meetup. Then 30th May sees a double-whammy: @Sotros25 running the SAFE Network: Chicago meetup whilst @ dirvine is speaking at the DigitalScotland 2019 conference in Glasgow.

It’s been a busy week for Nikita, travelling between Ayr, London and Brighton, but also to Berlin, where he was representing the team at the Data Terra Nemo Conference (you’ll find his tweetstorm summarising the conference here).

This is also a quick reminder about the various RFCs that are out with the community for comment at the moment: RFC #0054 (Published & Unpublished DataType: forum discussion), RFC #0055 (Unpublished ImmutableData: forum discussion), RFC #0056 (Secure Message Delivery: forum discussion), RFC #0057 (Safecoin Revised: forum discussion) and RFC #0058 (Reliable Message Delivery: forum discussion). As ever, if you have any thoughts or questions, please do get involved and help to drive each of these topics forwards.

SAFE API & Apps

The browser has seen some small updates merged into our dev branch: fixing the CI system after a Travis update; enabling F5 for reload on Windows; setting up the new end-to-end test system to be able to test the authenticator web page (this should hopefully open the door to enabling SAFE sites to have some automated E2E testing down the line); a slew of Dependabot updates to our dependencies and a couple wee fixes too.

We started also playing around with some experimental code for the SAFE CLI ideas we have, and as we mentioned before, we are documenting all these ideas more formally in a design document that we are very proudly sharing today. We are trying to follow the same approach or design as the safe_auth CLI PoC, in fact we are thinking of allowing the SAFE CLI to interact with the safe_auth CLI for getting authorisation credentials. We have just created a new post that explains the motivation around having such a tool for the SAFE Network. It's a long document because it is a SAFE CLI High Level Design Document, so you will be able to see how many use cases are planned to be covered by this tool. Please join us in the review and discussions around it.

SAFE Client Libs

The new data types that were introduced in the RFCs last week are being prototyped as a Proof of Concept in mock. This will help us quickly get them ready for the preview network once the RFC discussions are complete. The datatypes themselves are being pushed into their own separate crate. Going forward, Routing will be agnostic of the datatypes, and will only serve as a medium of transfer for serialized data. It now focuses on getting these payloads delivered from the source to its destination hassle-free. Clients and Vaults will share the dependency of the data types crate for the data type structures and the RPCs they exchange with each other.

This implementation of the new data types will initially be only for mock as it would be easier to modify and improve them iteratively with feedback from the community. This is being done to get a feel of the new data types and their use in application development. With regard to the RFCs, we'd like to thank everybody who has engaged in the discussions with their valuable suggestions and views. They are still open for receiving your comments. Please do check them out if you haven't yet and join the discussions about the published and unpublished data types and the unpublished immutable data type.

The implementation of RDF in SAFE Client Libs heavily relies on the datatypes in which they will be stored in the network, hence full priority has been given to the new data types and the RDF implementation is temporarily put on hold. We have already integrated the storing of RDF graphs in mutable data with the serialisation capabilities of the Turtle and JSON-LD formats. Integration of SPARQL querying is also taking good shape and will quickly be ready for action once the data types are implemented.

Routing

This week, the Routing team's march towards Fleming continues on multiple fronts.

Following the publication of RFC 56: Secure Message Delivery, last week; RFC 57: Safecoin revised was soon released too. There has been a healthy level of discussions, especially on RFC 57. Thanks to all who contributed to these discussions.

Internally, we prepared the RFC on Reliable Message Delivery which complements RFC 56 and should complete the big picture for communication of messages across the Network. This RFC was published today. Here is the associated discussion thread. We are looking forward to the generous contributions of this community to this discussion :smile:

We merged a couple of PRs to PARSEC. That crate is mostly in maintenance mode as we are happy with the features currently implemented; but we patched a bug that we caught when soak testing the integration of Routing and PARSEC. Note that the patch consisted in going from the concrete coin to an imperfect common coin. At some point (probably post-Fleming), we will replace it with a proper common coin; as described in the latest version of our whitepaper which is still under academic review. While we were at it, we raised another PR to refactor and add unit tests for the area of the code that contained that bug as we considered that this bug could have been caught earlier and fixed more rapidly if these tests had been there in the first place. This led us to close a number of Jira tasks that had been postponed as we decided to move them up the priority following this experience.

Soak testing of routing plus PARSEC has now started again and we don't foresee any further changes to PARSEC unless we discover more bugs.

In Routing, we identified and fixed a bug in mock-parsec and continued our incremental progress towards node ageing with some refactoring PRs and a couple of PRs bringing us closer to our functional destination. We now have solid flow using PARSEC to decide whether a node succeeded or failed resource proof, and only add them as a member when reaching consensus.

We were also thrilled to receive a few contributions from d1vyank on GitHub. We merged the first of three PRs he raised and are in the process of reviewing both others.

We also continued improving our routing_model crate which contains documentation for the endpoint we are targetting in routing with node ageing.

On the community front, last weekend, Pierre travelled to Odessa, Ukraine for the IT Non Stop 2019 conference where he gave a talk cheekily named: "Blockchain was just the beginning", where he contrasted some of the properties of blockchain with those of PARSEC. This talk was recorded and we will post a link to the video in the Forum once that is released. It was interesting to spread the word about the SAFE Network to an audience that mostly wasn't familiar with it. Many in the crowd seemed to really get the concept. They asked pertinent questions and engaged in interesting conversations :smile:

Last but not least, in-line with the company-wide effort of making project management front and centre as a tool to communicate internally and externally, we started drafting a detailed plan for the Routing team between now and Fleming.

Mainly, we laid-out the high-level tasks for each of the items outlined in the Backend GitHub board and broke down one of the largest ones: Node Ageing into a number of further named tasks.

Next week, we will do the same for Secure Message Delivery and Reliable Message Delivery. After this, we will list dependencies of these subtasks and this should enable us to produce a fairly detailed project plan that I am sure some here will be eager to browse.

Expect to hear more from us in the coming weeks!