Summary

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

Marketing

Following the developer feedback received on DevHub, we’ve started to implement some of the changes that we hope will improve the user experience. Today we added a new DApps page, which showcases some example applications developed for the SAFE Network, including the exciting, new community apps from @happybeing, @oetyng, @nigel and @glen_simister. We’d see this page getting regular updates as new DApps are developed, and to this end there’s a new Dev Forum topic where developers can submit their projects for inclusion. We’d be happy to get any feedback, or notification of amazing in-development apps from our community developers, so please don’t be shy!

And @oetyng has popped up once again! This time, he’s been good enough to answer a few questions about his SAFE project in an interview (check out Part 1 and Part 2). Finally, some of you might have noticed a tweetstorm we put out earlier today. We’re planning to do a regular roundup of stories of interest to SAFE followers but looking for inspiration for a name! So if anyone has any thoughts, please just add them to the thread below.

Recruitment

A couple of pieces of housekeeping to update you with this week. A month or so ago, @douglas.santos joined the Crust team but he’s now taken the decision to move in favour of working on an in-person, rather than remote, role. He leaves with our best wishes - as does @povilasb who alas we’re sad to report is also moving on. We’ve known for a while that Povilas planned to move to New Zealand and unfortunately managing the different timezones in such a collaborative project as Crust is not ideal. So we’d like to thank him for all his hard work over the past few years as he goes to work on a few personal projects - he’ll be sorely missed and we look forward to seeing him continuing to pop up in the community as we move forwards. And who knows what the future may hold!

Inevitably, from experience, we understand that some people question why people choose to leave. So for the record, it’s worth reiterating that both reasons are unrelated - and it’s crucial to note that we are actively recruiting to fill the gap! You may have seen our tweets - so this is where you can all help! Please do share/intro/point us towards anyone that could be a great fit in building the next Internet as we look to fill that gap!

SAFE API & Apps

We made available a new version (v0.11.0) of @maidsafe/safe-node-app. For details of the changes and additions included in this new release, please refer to the CHANGELOG. Apart from all the technical changes included in this release, it’s worth highlighting the enhancements made to the documentation available in the README file. Among other things, it now explains in much more detail how this package is structured so new developers can better understand it, how to contribute to the project, and gives a high-level overview of the API.

As we’ve been mentioning in the last few dev updates, within the front-end team, we were researching and working on a first command line user interface since we understand that GUI may not be ideal in all circumstances for users and developers. We believe there are certain use cases where having CLI tools can provide additional benefits and support more types of applications (and/or types of users) than only having GUIs.

This is why we started by exploring the possibility of having a SAFE Authenticator CLI, which interacts directly with our SAFE Client Libs with Rust, and we are very excited to share it with all of you today. Note this small project is in its nascency, and we are trying to get the community engaged in its progress at this early stage. We have created a new thread with more details about how to use the CLI, and also to use it for all discussions and support related to it:

SAFE Authenticator CLI Apps While the SAFE Browser provides an integrated Authenticator GUI for users to create and manage their SAFE Network accounts and authorised applications, there are many situations where being forced to use a GUI, such as the browser, is less than ideal. For example, developers working on a desktop SAFE application, either during development, testing, or even the debugging phase, may find it uncomfortable or overkill if all they need is just the app’s credentials to connect to the SAFE Network to …

In browser land, we’ve had a pleasant week. First off, we got a new browser version release (v0.12.0).

Beyond that, we’ve been stabilising our CI E2E tests. We’ve dropped Spectron (which is based on Selenium), for a new, vastly more reliable test runner called TestCafe. For the browser UI tests, TestCafe has proven to be actually reliable. This is a big step up from our previous, brittle Spectron tests. We’ve also made a good whack at standardising our code base, reducing linter bugs considerably. And we’ve got a potential solution for reintroducing Windows builds (now with Travis), which is also working well with the new TestCafe setup. This involves tweaking how we manage the native lib dependencies in safe_app_nodejs and the browser (in order to avoid some obscure Windows issues which have broken the CI recently).

We are glad to announce that v0.1.1 of the SAFE Messages app was released this week as an updated PoC. See this post for more information. You can download the latest APK from this GitHub release. Have a look at the changelog for the list of changes.

SAFE Client Libs

We’re glad to announce that this week @lionel.faber joins our team to work as a full time Rust developer. He’s been doing exceptional as a member of the Mobile Dev team and we’re looking forward to his contributions to SAFE Client Libs!

This week saw continued work on the documentation, with us adding a Core data types page to the wiki and an About section to the Readme. We made a number of edits to the Introduction and Contributing pages trying to make them more accessible, based on feedback from @davidpbrown. We are also improving the FFI code documentation as well as fixing a few FFI bugs that we noticed while writing up the FFI pages. In addition, we want to thank @mav and @southside for their recent Pull Requests to the project – your contributions are highly appreciated!

Work on the RDF front has been slowed down a wee bit during the last week due to @nbaksalyar joining the Crust team to help with the current projects. However, we’re staying on top of things and considering many of the valuable comments we’ve received both from our community and team members. The work on RDF proof-of-concept will also reignite soon with Lionel joining the team.

Routing

The Routing team is continuing its march towards Fleming.

On the Parsec side, we decided last week to leave out a number of tasks for after Fleming was real. We now moved all of these to a “Parsec-milestone-3” milestone in Jira so that it is easier to track the remaining progress of Parsec needed for Fleming (Parsec-milestone-2).

Of the tasks that do need to be tackled for Fleming, we tackled a good chunk this week.

We added tests for a couple of new malice detections: InvalidSelfParent and InvalidOtherParent .

We recently changed the way gossip communications are represented in the gossip graph by adding a Requesting sync event. This allows creating a structure that can easily and cheaply be inspected for correctness. This week, we used this new structure to detect malicious gossip patterns more easily than we would originally have.

A bug in the detection of interesting events was also fixed, and another bug in the way see ing is defined in the presence of forks.

We are satisfied that our PARSEC v2.0 (properly asynchronous with a common coin) paper is as ready as we’ll get it, and we have submitted it for review to the Journal of Parallel and Distributed Computing. This process may be lengthy (12 weeks average time from submission to first decision. 45 weeks from submission to acceptance), but we hope it will help us make the paper as tight as possible through academic review, and gain some academic recognition for the algorithm. We will keep you up-to-date as the review process progresses.

On Fleming, we are getting closer to implementation by firming up our understanding of node ageing. We actually started some refactoring work in Routing and are progressing the implementation specifications for other Routing changes needed for Fleming.

We are all looking forward to being able to dive into the Routing code and making the magic happen

Crust

This week we implemented two binaries to help us test the QUIC based Crust implementation. We use bootstrap_node and client_node to spawn multiple Crust nodes, connect them together and exchange some data. With those tools in hand, we started aggressively testing our implementation. As is expected when testing some bugs have been found in quinn itself, which we’re helping to fix, and the quinn folks are very helpful and effective at solving those issues.

We keep pushing quinn to its limits and in the meantime we also considered an alternative QUIC implementation in Rust: quiche. quiche turned out to be less ergonomic to use. It is sans I/O implementation and we would need to implement the I/O layer ourselves which quinn already has, hence quiche was not considered any further.

To be clear, the QUIC spec since becoming managed by the IETF really is a very attractive protocol for secured P2P networks. This is a large departure from the original server focus. The reason we are spending time here is that QUIC is basically what Crust was intended to be. Of course, we have our own parts, such as random ports, restarts, bootstrap cache, etc. but fundamentally the underlying protocol is close to perfect for us. In addition, it means SAFE engineers no longer need to be network protocol designers and that itself is a huge boost for us. The hope here is that with QUIC we can align with new Internet standards and simply use the protocol that now meets our requirements of security and accessibility. Very exciting to work with this protocol and see just how the rest of the Internet is seeing things as we did so long ago. In essence, this test, if successful, means we can focus on SAFE and less so on any network protocols.