Summary

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

Marketing

We’ve got a number of upcoming meetups to draw your attention to. First, @nbaksalyar will be speaking at the inaugural SOLID London meetup on Wednesday, May 22nd about how we’ve been using RDF within the SAFE Network. The following night Thursday, May 23rd there will be another SAFE Network: Brighton meetup. In addition, there’s going to be the first ever SAFE Network: Glasgow meetup on Tuesday 7th May and there will be another edition of the SAFE Network: Chicago meetup next month.

If you haven’t seen it yet, it’s well worth taking a look at @dirvine’s video interview for FutureScot in advance of his talk at the annual Digital Scotland Conference. There’s been another tweetstorm highlighting some of the key stories of the week and we’ve been working with @hunterlester who has released a tutorial running through how to build a Node.js application for the SAFE Network.

In the meantime in the background, the work on DevHub has been continuing and we’d like to again highlight the new MAID listing on the Bitker Exchange for anyone who might have missed the news over the last week or so. It’s probably worth mentioning that whilst we can never recommend one exchange over another, as with all exchanges for this listing to be maintained, there needs to be a minimum daily volume. In this case, the exchange requires daily trades of MAID of at least 1.5BTC value. Therefore, if you are intending on trading MAID, please do at least investigate Bitker whilst making your decision about where best to trade. We’ll continue to pursue options for exchanges that are cost-effective and we’re keen to do our bit to help ensure the community has alternatives where possible.

SAFE API & Apps

This week we integrated the safe_app_csharp repo with coveralls.io for code coverage.

We added additional unit tests for scenarios such as session disconnect and reconnect, creating private mutable data with specific XOR name and encryption key, updating private mutable data permissions for specific user public sign key. These unit tests can be used as a reference while building applications.

Also, we’ve added an Azure DevOps CI build pipeline to build and run .NET Core tests on Linux x64 platform. Check out the README file for updated code coverage report and build status for all CI services for the master branch.

We’ve recently made the necessary changes to the safe_auth CLI needed to build it for both the Mock and Non-Mock (e.g. Alpha 2) network, and we updated the README to explain how to build and run the CLI for any of these networks. We were also able to fix a couple of tests which were disabled and are now passing. One of the main next steps for this project is to research how should an API exposed as a web service look, what type of standard/s we can use for such an API which enables good interoperability with other SAFE applications, not only desktop apps but also mobile, IoT, etc. There are several ideas on the table we’d like to research, e.g. JSON-RPC, Cap’N Proto, Protocol Buffers, FlatBuffers, gRPC, etc.

The browser’s being prepped and tested for a new release coming soon. And preparation for the subsequent release is also ongoing. With another Electron version recently released (v5), we’re hoping to get back in sync there. This has in turn involved some more tweaks to the underlying FFI libs in the browser and safe_app_nodejs.

SAFE Client Libs

With the required changes made in the newly published version of safe_bindgen and with some help from @tfa we have completed the migration of SAFE Client Libs to the latest stable Rust 2018.

The improvement in the API also continues. We have renamed the use-mock-routing feature to mock-network to make it simpler to understand. More improvements are being planned and will be implemented soon! @lionel.faber and @yogesh have also started looking into the Redland libs for RDF to study and understand the API.

Routing

This week we completed the last of the main PARSEC work. With our unified team once again, we are focussed on getting our Routing code ready for Fleming.

This week was focussed on progressing the 3 parallel lines of development mentioned in last week’s Dev Update:

First, we continued with our state machine clean up: PR 1613 is progressing well and undergoing final testing. We aim to complete this work with currently in progress PR 1615 and PR 1616. With some additional fixes to allow our test to run robustly with PR 1612, we are getting in good shape for more developers to collaborate and contribute to the Routing code base effectively.

We also progressed with our Message Relay update. We have part of the implementation well underway and are trying to iron out some issues. We are aiming to keep that work minimal, but we are also learning from the issues we found and are refining our design on how the system needs to work for Fleming.

Finally, we have progressed our Node Ageing routing_model to the point we can start extracting some detailed implementation specification for standalone parts of the design with a view to start implementing them. More work is ongoing to provide the complete picture of the system and also to validate that it behaves as expected with additional tests.

Thanks again to @oetyng for his naming review! We followed up with an initial PR to follow his excellent advice in our Routing code.

QUIC-P2P

There is a lot of news this week as we’ve been continuing to direct our attention to quic-p2p.

We’ve finished the implementation of bootstrap, a crucial feature for a P2P networking library. When bootstrapping, we try to connect to multiple peers at once but select only one successful connection, enabling a quicker start-up of a connection with the SAFE Network. It also uses the bootstrap cache, a list of known good peers, which makes the connection process even more seamless, and also, importantly, prevents the possibility of censorship.

In parallel, we keep adding more automated tests for different scenarios, including bootstrap and peers with malicious intents. These tests helped us to uncover more edge cases and some bugs in the bootstrap logic. We’re fixing this now.

Usability also remains one of our main targets, so we’ve made quic-p2p more configurable by using structopt . It’s a Rust library which allows building command line interfaces in an easy, reusable, and composable way. It’s gaining popularity in the community lately and we are happy to follow this trend, making our libraries more interoperable with others.

Lastly, we don’t forget about Quinn, the underlying network protocol library we use. We proposed an optimisation for the stream read function which, as we discovered, needlessly reallocated memory many times, possibly affecting performance. The Quinn team has been very responsive as always and quickly produced a patch which is now merged.