Summary

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

We released an updated C# API and new tutorials for .NET mobile and desktop development on the SAFE Network. See this post for more details.

The Routing team released a first forum post to start shedding some light on the work that they are doing to prepare for the Fleming milestone.

A few MaidSafe team members will be at FOSDEM this weekend. See this forum post for more info.

Marketing

It was fantastic to see Devolution, a new DApp developed by @Glen_Simister, pop up on the Forum out of nowhere this week! If you want to see his vision of how an open-source application can be used to build communities with political autonomy, you can read more about it in this forum topic.

This afternoon, @fergish has been recording a lengthy new SAFE Crossroads podcast with both @dirvine and @viv. It should be published (at least the first part) early tomorrow morning (UK time) so please keep an eye open, have a listen and feel free to share it widely!

We also supported the C# release this week, together with another monthly summary of SAFE Network goings-on that you should see published within the next couple of days. Video content has also consumed a fair amount of time this week. For example, after a very successful SAFE Browser hangout last Friday afternoon, the video needed a little creative editing to get around the initial technical difficulties we had - but the call itself was really successful, with lots of great questions from the participants. We’re hoping to work with the Devs to get more of these calls on a more regular basis moving forwards so please shout if there are any topics in particular you’d like us to get arranged.

We all enjoyed the Data Privacy Day banter online earlier this week - and interesting to see many people hoping that regulation will solve the problems of a broken internet… Also, @dugcampbell has just been confirmed to speak at the Landing Festival (3-4th April 2019), which will have over 1,500 attendees. We’re considering maybe running a SAFE Meetup in Berlin the night after the festival - so give us a shout if you’re in the vicinity and it might be something you’d be up for coming along to!

SAFE API & Apps

This week we released an updated safe_app_csharp API and API documentation for .NET mobile and desktop development. We also released example apps for desktop (Windows) and mobile (Android, iOS). New tutorials have been added to the DevHub to help developers get started with development on desktop and mobile. Check out this forum post for more details.

Scoping continues for the next milestone for safe_app_java . The team has put together a couple of PoCs that will improve our test suite and CI setup. In parallel, we are also putting together some documentation for the project structure to help developers find their way around the code and start contributing.

Browser wise we’ve been looking at where we can further stabilise things, which has seen us taking a closer look at tabbing in the application, and what we can simplify therein. We’re also trying to get the browser running against newer versions of Electron itself, which while not being as simple as one would hope, we’re making progress on.

Similarly, we’re scoping out a new release of the FFI library in safe_app_nodejs which should provide compatibility for newer Node versions (hello 10.x!), as well as being a precursor for the aforementioned Electron updates.

SAFE Client Libs

We’ve been continuing to work on the Proof of Concept for storing RDF triples in network Mutable Data. This week was spent working out the serialisation internals of librdf (the RDF implementation we are building on top of). Something in our implementation was (and is) causing this step to fail and our priority is to fix this as soon as possible. The next step will be to reuse RDF’s triple hashing so that we can more efficiently store triples as key/value pairs in Mutable Data (the scheme we currently have in the POC is a placeholder for this). Progress on this POC can be followed here. In the meantime, the RFC for bringing RDF to SAFE Client Libs is getting closer to completion. We’re going to publish it soon and start the discussion process.

Recently @yogesh joined our team and he started with helping us with some outstanding tasks. The first one is switching SAFE Bindgen to another parsing library. This is required because recently we’ve switched to always using the latest available stable Rust compiler, and the parsing library we currently use in Bindgen is deprecated and not supported anymore. Consequently, it does not recognise some of the new syntax constructs that appeared in the recent Rust versions, and it fails to parse the SAFE Client Libs code using this syntax. Getting this work done will allow us to completely switch Client Libs and the rest of our repositories to the latest Rust version.

In parallel, we’re continuing to document the core concepts of SAFE Client Libs and scoping out the remaining parts of the libraries to cover. We’re considering this an important milestone and we’re aiming to make this documentation public soon.

Routing

The Routing team continues sharing effort between Fleming preparations and the implementation of Parsec.

One aspect of our work that overlaps between both consists of addressing the scalability of Parsec with various section sizes. As noticed here by some astute community members, we have continued to make serious progress on this front as we merged a change that drastically reduces the number of calls to the function is_interesting_payload and improves performance by > 50% for larger section sizes.

As we can now easily measure the scalability with section size, we can see that more work is still needed here. We are already following interesting leads to get even further improvements. For instance, we used Callgrind to establish that the function meta_votes_since_round_and_step is called much more often than expected. This is really good as it gives us an opportunity to keep improving the code.

Since last week, we continued troubleshooting soak testing failures. We fixed a problem with the test framework that was causing some of these failures. This allowed us to identify another one, apparently coming from a bug in the production code. At first glance, it looks like a peer reaches consensus on the same block twice. We are still tracking that particular bug down.

We are also continuing to investigate a performance issue related to “accomplice” malice handling.

We are also continuing to prepare for the Fleming milestone with design discussions.

Yesterday, we released a first forum post to start shedding some light on the work that we are doing in this area. This article sets the scene. It will be followed by more articles that will dive into specific technical aspects of our work as we move forward.

Finally, we continued running simulations to estimate the impact of various Routing design parameters such as the section size, the number of elders per section and such on the security of the Network. We are refining our conclusions and will continue in that direction by varying a number of parameters in our simulations to get a more complete picture. This work is still progressing. We expect to communicate more details about it when it allows us to crystallize certain specific aspects of the design.

Crust

Finally together with Luka’s help we did some bootstrap cache improvements. Now Crust will try to maintain the list of the most active 200 publicly reachable peers and use those to bootstrap off.

We’ve been spending a great amount of time refining our nearest roadmap. We are defining more concrete milestones and prioritizing them to make the Fleming release happen sooner. Some of the things that need to be taken into consideration are node restarts, network upgrades, connection limits, etc.