Summary
Here are some of the main things to highlight this week:
- A new and improved version of the SAFE Network Primer is now available.
- We have another SAFE Buzz live on YouTube, this time with @nbaksalyar.
- @cgray shared a beginners guide to Self-encryption on Medium.
- @AshwinKumar has recorded a new video where he works through the .NET development tutorial and we’ve added it to YouTube.
- Work on PARSEC is very nearly complete as far as preparations for Fleming go. This means the full Routing team will soon be reunited. There are some backlogged PARSEC tasks which will likely need to be addressed before Fleming is released, but for now the priority is Routing.
Marketing
A busy week for us here in marketing. First up, we had @cgray sharing her beginners guide to Self-encryption. This is the first in a series of where we’ll explore different components of the Network and, by taking a simplified viewpoint, hopefully enable those of us not as technically skilled the capability to understand the Network. We have another SAFE Buzz live on YouTube, this time with @nbaksalyar. A little longer than the other ones, Nikita chats through his career background, what he does here at Maidsafe and, most interestingly, the work he is doing on Client Libs. It’s a good watch so we encourage you to check it out! And…another Tweetstorm! Fresh off the press is the updated Primer, which is the result of a lot of hard work by @JPL. I know many more people were involved so a big thank you to all that contributed. It’s a fantastic, well-used resource and the new additions such as PARSEC and the fundamentals means all the most up to date information is now hosted in one in one place.
DevHub has had a few more tweaks added to it this week with GitHub and API links being added to each component within the Core Technology page.
@AshwinKumar has recorded a new video where he works through the .NET development tutorial and we’ve added it to YouTube. We’re looking at putting these video walk-throughs into all of the DevHub platform tutorial pages as well.
SAFE API & Apps
We’ve been working on documentation enhancements for the safe_app_csharp package and SAFE Authenticator mobile app. The README files in both repositories now include more information for users who want to build and use the safe_app_csharp
package and/or Authenticator mobile app. For developers who are interested in contributing to these projects, the README file now has details about the project structure, useful resources and how the development tasks are organised in the project boards.
This week we’ve been digging into a couple of issues that were blocking Electron upgrades. This resulted in PRs for safe-app-nodejs, and weak-napi
, which have been accepted and merged. This let us upgrade to use this library for more modern FFI integration, which led to a new patch release of safe_app_nodejs (0.11.1). Using this, we’ve finalised a PR for upgrading the Electron version in the browser, which should itself, unblock a few more issues that we can now get started on. With this new patch release we also started aligning to Conventional Commits and we started using the standard-version tool for bumping the version of the safe-app-nodejs
package and changelog updates automatically, just like we’ve been doing for the SAFE Browser package releases which has shown to simplify the task for us.
QA has also hooked us up with Dependabot for the browser just now. Which should help keep our dependencies up to date.
A few unit tests have been recently added to the auth CLI internal API. We were also researching a bit about having test coverage for this crate using kcov. We are not sure yet how/if that’s going to work out as expected but we’ll see. Some of the very next steps are to make the necessary changes to be able to use the auth CLI with the real Network and not only with Mock, and to prompt the user to allow/deny each authorisation request (or optionally set to allow all with a flag). As a reminder, we have a dedicated thread for the auth CLI for discussing any problems and/or ideas related to this crate/app, so please jump in, we’ll be glad to hear your ideas and help as needed.
SAFE Client Libs
This week we’ve been finishing up the work on porting SAFE Bindgen from using the syntex_syntax
crate to using syn
. syntex_syntax
is a deprecated crate for parsing Rust code and it is not able to parse code from the recent stable versions of Rust. This was blocking us from moving Client Libs to the newest Rust compiler version and to Rust 2018 as we had to freeze the version at the old 1.29.1, as otherwise SAFE Bindgen would fail to parse the code. This in turn was causing our documentation to be missing for SAFE Authenticator, as docs.rs always tries to use the latest Stable to build the docs. Several of our outstanding PRs have also been blocked for some time while we wait for Client Libs to be upgraded to Stable.
@yogesh did a great job with the SAFE Bindgen changes and the code is compiling. We are still waiting for the changes to be thoroughly tested, and a new version to be published. We also require some changes to be published in FFI Utils before Client Libs can finally be upgraded, but we are very close. Client Libs seems to be working when we build it locally with the latest Bindgen and FFI Utils changes, but we are still running integration tests on our various supported platforms.
Apart from that, @marcin worked on fixing some errors in the documentation and implementation of FFI in Client Libs, and the PR has been merged. He also continued work on documentation with a new page on continuous integration. Additionally, our newest team member @lionel.faber has been contributing to the codebase with an excellent PR adding application management to the public API as well as another PR publicly exposing the run
helper function.
Finally, we also worked on incorporating some changes proposed by community members. We have merged @mav’s PR adding functionality to our Client Stress Test example, and we are working on changes proposed by @tfa, with the work being done here.
Routing
Work on PARSEC is very nearly complete as far as preparations for Fleming go. This week saw us pick off the last few tasks related to testing, particularly the malice-handling code, and we’ve also implemented a couple of bugfixes which they revealed. With only one outstanding task remaining before the full team is reunited, we’re hoping that this will be completed by the end of this week. There are some backlogged PARSEC tasks which will likely need to be addressed before Fleming is released, but for now the priority is Routing.
Speaking of which, Routing had advanced somewhat this week too, both in terms of documentation and code.
Work has continued on documenting the various logic flows in Routing, expanding on those mentioned last week and improving the existing ones. We have now documented the flows for section merges and splits and for nodes coming online or offline too.
As for implementation; the message relay refactor is progressing well, having reached the testing phase. As ever, handling message relay in the context of section merges has proved to be a little tricky. Also, having replaced the former mechanism of retries down various routes, we are having to come up with alternative fixes for cases where nodes are lagging a bit. Previously the route-retry would paper over such issues, allowing slow nodes to catch up when the retry fired.
Crust/Quic-p2p
We now have a relatively stable version of the using-quinn
crate that we were working on and that’s now been moved under a MaidSafe repo ready to be consumed. As the README says it brings a lot of good stuff to the table with IETF compliant work underneath. We have solved and helped solve most of the bugs now and unless the protocol is taxed too much, our tests pass on the DigitalOcean droplets that we spawned for it. We continue monitoring throughput and help the quinn team improve their library further with regards to congestion control etc., so that we can tax the protocol at-least as much as we can with say TCP.