Summary

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

Roadmap

Over the past few weeks, we’ve been working hard on pulling together a Roadmap in order to give certainty to the community about our immediate and medium-term priorities. Everyone (internally and externally) is clear about what the ultimate SAFE vision is - but of course there are many different alternative paths available to us in order to arrive at that same destination. Consequently, the discussions have been centred around how we get to the launch of an MVP which (1) does not simply get attacked on release, and (2) does not sacrifice any of the fundamental SAFE characteristics without which the Network would be a pale imitation of the goals that we’ve always pursued.

We’re happy to say that in next week’s update, we’ll be publishing the updated Roadmap for the SAFE Network. This will be in a format that should bring clarity and allow us collectively to ensure that everyone is on the same page when it comes to the path ahead. As you would expect, it is easier to be clearer about the short term roadmap while medium and longer term features will have less detail and may change. We’ll never be able to satisfy everyone with the details (we won’t be publishing a launch date, for example) but we hope that everyone will find the information useful and a significant improvement on the information today which is captured across many different locations and conversations.

Marketing

This week, we released a new video intro to Sybil Resistance on the SAFE Network by @jonhaggblad. We also released a new post on the topic (on Medium and the Forum).

We’ve also released an update on QUIC, Quinn and Crust

(on Medium and the Forum) plus @ustulation has recorded a video discussing Quinn and the adoption of QUIC P2P. In addition, we’ve also released our monthly update for April.

To explain, we’ve cross-posted these articles in response to feedback that some are keen to avoid using Medium. However, given the marketing impact this platform still provides us with (automatic emails, viral reach, readership outside the existing community, etc.) we will be continuing to use it - so even if you first read the article on the Forum, please do go onto Medium and give the article support (i.e. claps) as this increases the opportunities for people outside the existing community to learn about the SAFE Network.

We’re considering this further internally because the articles written for Medium are specifically targeted at a more general/beginner audience. Often that content will be simplified and shortened so we’re exploring how to ensure that simple cross-posting won’t appear too simplistic on the Forum (where by definition much of the audience has at least a passing knowledge of the Network already). We’ll speak more about this next week.

On the subject of exchanges, a quick reminder to check out the new MAID BTC/ETH/USDT listings on the Bitker Exchange if you haven’t already and are trading MAID. Finally, if you use OpenLedger, please ensure you read this update and remove any MAID. And finally, a reminder of the upcoming meet-ups - Glasgow (Tuesday 7th May), SOLID London (Wed 22nd May) and SAFE Network: Brighton (Thurs May 23rd).

SAFE API & Apps

This past Tuesday we released a new version of the SAFE Browser (v0.13.0), which brings in several bug fixes and enhancements such as having a nicer popup for the Authentication notifications feature. You can find more details and instructions to download it in its dedicated forum post, where we provide help for issues faced by users.

We received some really helpful feedback and help with testing the safe_auth CLI from the community (thanks a lot to @tfa and @draw!), with a bug that is now fixed, plus some suggestions for enhancements that we added to the backlog/todo list. We are also trying to apply to this project a similar process that we’ve been internally using for the development of the SAFE Browser and incorporate the help of the QA team, and we anticipate the additional ideas and suggestions that will bring will help to advance the project. You are very welcome to look at the safe_auth CLI project board to get more details of upcoming tasks and/or ideas we are throwing at the table.

The Electron project have been releasing several new versions in the past few months which we couldn’t keep up pace as we wished, so we are now trying to catch up by aiming at upgrading Electron to v5 in the SAFE Browser, and in our safe_app Electron app boilerplate that is used for the tutorials on the DevHub. We already started working on this in the last few days, and we were and still are facing several issues but we are now very focused on getting it done and hopefully having it ready for the very next release of the browser. We believe this should solve several minor issues we currently have in our browser and therefore it’s a good moment to complete the upgrade.

We have however gotten the browser up to Electron v4 successfully, and are building on top of this with a flurry of fixes and features this last week. Including a better, more feature-rich right-click menu, some more wee UI tweaks (thants antd !) and more stable URL-opening with multiple windows. We’ve also been tweaking our workflow, to try and prevent PRs (and all that rebase/merging fun) from stacking up too much. You can read on the repo itself, but may be worth noting for folk here that we’re now working on the [ dev branch] of the browser, and any/all PRs should be pointed there whereas master will be the latest stable release of the browser from now on.

For those CLI lovers (like some of us ), we were researching and thinking, for a few weeks now, what a safe CLI may look like, a CLI which allows users to manage all kind of SAFE Network data. We don’t have much more to share yet, but we are very excited to at least share that we started working on documenting some of these ideas towards having an RFC for such CLI. We are trying to get this sooner rather than later as we want scrutiny from the community at an early stage, thus stay tuned that we’ll be sharing more news on this front hopefully soon.

SAFE Client Libs

It’s been an interesting week for SAFE Client Libs as @lionel.faber and @yogeshwar continue exploring the internals of the Redland RDF API. The Redland C libraries provide APIs to work with RDF graphs and SPARQL queries, so it’s important that we understand their design and implementation while writing Rust bindings for them.

In parallel, we are also working towards the improvement of our codebase. We fixed a bug that caused safe_bindgen to generate unnecessary duplicate code and we are improving the crate by fixing a few bugs and adding more tests too.

We’d like to give another shoutout to @riddim and @dask for their impressive work with the Python bindings for SAFE App and a proof-of-concept chat application! If you haven’t tried it out yet, visit their post and show some love.

Routing

As per last week, the main thrust of our efforts has been towards getting Routing ready for Fleming.

The refactoring of Routing’s state machine has continued and is nearly complete with just PR 1616 still pending. In parallel, the refactoring of the message-relay mechanism has been ongoing, with some discussion on the various options available to us.

We’ve also begun to implement some of the changes needed to handle relocating nodes/node ageing, using the flows described in the routing_model crate for the design. Work on this crate has also progressed, with some cleanups and additional tests being added.

The degree to which Routing abuses PARSEC in its aggressive churn tests has allowed us to find another edge-case bug in PARSEC. Work on resolving the issue is continuing, but this has also caused us to rethink our decision to postpone some of the PARSEC test tasks. Its own test suite should have been sufficient to catch this bug, so we’re in the process of implementing some of these backlogged test tasks.

Finally, @jonhaggblad has created a video giving an overview of the Sybil-resistance mechanisms in the SAFE Network.

QUIC P2P

We are continuing to enhance the library and covering more test cases. This week, @ustulation added code to retain messages that were not sent for some reason (e.g., due to a networking error). These messages will be returned to a user of the library and can be attempted to be sent again later. This brings us more robustness and we can be sure we guarantee to not lose any messages users send. As mentioned in the pull request description, this can also be improved further by implementing app-level acknowledgement messages if we would require even more robustness.

We are also continuing to work on adding more tests for the bootstrap process and covering more edge cases and failure scenarios which could happen during peers bootstrapping. We’ve implemented some simple testing utilities to help us with this task: e.g., they allow us to introduce artificial delays for certain connections and writes. It should also help us to cover more test scenarios in the future.

There has been an interesting discussion on the forum about our move to QUIC, and we’ve been answering some interesting questions from our community members: