Here are some of the main things to highlight this week:
- We had the first of what will hopefully turn into a regular catch-up with SAFE meetup organisers today. Lots of valuable feedback and ideas were shared on the call about how best to build and engage communities of supporters which we’ll share very soon.
- The front-end team has reordered their priorities for the next month in order to prepare for the dev conference in April. They would like to get the dev website ready for the conference. They are therefore pausing the UI/UX work for Peruse to focus on getting the dev website ready.
- The SAFE Client Libs team developed a new FFI function,
test_simulate_network_disconnect, that exposes a previously hidden function that simulates network disconnects. This should help the front-end and app developers to test apps in conditions where the network connection is unstable.
- The Routing team is continuing with the work of figuring out an approach to deduce a consensus order of observed network events from a Directed Acyclic Graph (DAG) which was composed from the gossiped messages. They have some test code in a private repository that they have working and will progress this to an open solution. We just published a blog post regarding this, you can read it here.
- The Crust team finalized and merged the chat example.
New SAFE Developer Website
As you’ll know from past updates, we’re currently redeveloping the MaidSafe website (https://maidsafe.net/). During that work, we’ve taken a broader look at our online presence and decided that we should build an additional, standalone Developer website. This work is now underway and we’re looking at a release of this website in the very near future. More to follow on this in due course.
SAFE Meetup Organisers Call
We had the first of what will hopefully turn into a regular catch-up with SAFE meetup organisers today. Lots of valuable feedback and ideas were shared on the call about how best to build and engage communities of supporters which we’ll share very soon. Thanks to everyone who took the time out of their day to dial in - and apologies to those who couldn’t attend due to various time zone clashes. As ever, if anyone has any views on meetups or community building when it comes to the SAFE Network, please just contact @dugcampbell or email email@example.com.
Activity on r/safenetwork
As pointed out by @riddim earlier this week, it’s worth noting that there seems to be increasing levels of activity on the subreddit. Thank you to everyone who has been engaging there and helping to spread the word.
Out and About
We have reordered our priorities for the next month in order to prepare for the dev conference in April. We would like to get the dev website ready for the conference. We are therefore pausing the UI/UX work for Peruse to focus on getting the dev website ready. Though the UI/UX aspect is paused, the technical aspect of the work in Peruse will continue to be carried out in the meantime. The work is in line with the features that we were planning to have as part of the UI/UX update. Once Jim (our new UX Designer) is also part of the team, we will continue working on the UI/UX designs for Peruse.
@lionel.faber has been trying to get a grip on the safe_app_java codebase. He is proving to pick things fast and we are hoping to see more progress there in the near future.
This week we’ve been testing the latest Peruse changes, and have tracked down and tackled some awkward Electron bugs that were preventing the new background processes from loading properly in the packaged apps. We’re now moving on to ensuring that e2e tests are working in the new setup, before taking a longer look at the DOM API updates we’ve been planning.
As briefly mentioned in previous dev updates, we are exploring ways to enhance our DOM API by removing the handles that are currently needed for each object created through it. We are considering simply exposing the safe_app_nodejs API within the DOM API, with a few exceptions for the functions related to the authorisation requests. These few exceptions are due to our wanting to prevent web apps from needing to send/receive auth requests/responses through the system URI mechanisms and instead using the internal IPC mechanisms as we do today, avoiding all complications we may face with different platforms. This will not only simplify the internal design and implementation of the browser but also make the DOM API much simpler and coherent with the safe_app_nodejs API, allowing app developers to have almost the same codebase if they want to release an app as a desktop and web app.
This week we developed a new FFI function,
test_simulate_network_disconnect, that exposes a previously hidden function that simulates network disconnects. The PR was merged earlier today. This should help the front-end and app developers to test apps in conditions where the network connection is unstable.
We’re continuing to work on the C# and C bindings improvements which turned out to be a little bit more complicated than expected because the library that we used before to generate C headers, moz-cheddar, got deprecated and is no longer maintained. Now we’re integrating the C language support into our safe_bindgen framework which is already based on
moz-cheddar and is now tailored for SAFE Client Libs. As a result, we should get fully supported headers for C, with examples and automatic tests. The progress can be tracked in this JIRA task.
We are continuing with the work of figuring out an approach to deduce a consensus order of observed network events from a Directed Acyclic Graph (DAG) which was composed from the gossiped messages. We do have a solution that is not available as open source right now and we cannot use that exact algorithm. We have some test code in a private repository that we have working and will progress this to an open solution. We just published a blog post regarding this, you can read it here. So on to the good parts, this ordering consensus algorithm for intra section membership changes is nice and modular as well as mathematically proven. This means less code, less testnets (many testnets were to find all the rules regarding order, which have grown in complexity (although works)). We cannot say this is definitely the last unknown as we have not detailed network restarts after complete collapse or network managed upgrades amongst others, however this is a large step and one that allows us to much more clearly see the remainder of the features for a full-featured network, or in other words Beta. Much of the work (and there is an awful lot) is currently hidden here, but will be exposed very soon. We ask for a little patience with us in Routing for the next few days and possibly weeks. If this pans out then it will be very much worth it and you may find us able, at last, to give reasonable estimates of remaining development work. This does not mean detailed roadmap with timelines, but we will have a very clear route and make it clear which tests we wish to do, most of which will be in client APIs, language bindings and platforms.
In Crust, we finalized and merged the chat example. It is quite flexible and allows us to examine misc aspects of Crust and, as a result, we found 2 new bugs that still have to be investigated and fixed (2589, 2588). Also, we’ve been working on slightly changing the
Service::connect() API - Crust will do connection information exchange by itself, all you’ll have to do is provide a relay channel to
connect(). But it’s worth noting that the compatibility API will remain the same. netsim is paying its dividends: it helped us spot bugs in both the Crust and p2p crates which got fixed and covered by netsim based tests. Also, we started working on another tool called nat-probe. It is meant to help us test the existence and type of a NAT: is it a full-cone NAT, does it support IGD, etc. Hopefully, this tool will save us tons of hours of debugging in the future.