Summary

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

Marketing

In amongst a couple of last minute holidays before the end of 2018, the Marketing Team has this week focused mainly on the SAFE Browser release. If you haven’t already, please check out the Medium post (‘Keeping 2018 SAFE and Solid’) and also @fergish’s new podcast (SAFE Crossroads #49, What’s So Special About the SAFE Browser’). We’ve taken on your feedback regarding the weekly Dev Update video and we’re going to have a think about some alternative approaches here - more in the New Year on this front!

SAFE API & Apps

The new version of the SAFE Browser (v0.11.0) was released yesterday, bringing with it many enhancements and some new cool features, especially around supporting RDF, WebIDs, and linked-data in general with the introduction of XOR-URLs. Please refer to the SAFE Browser release post to learn in detail what this release is all about and how to start using the new cool features and tools we made available with it. E.g. we updated our Patter social app to allow users to share files by simply attaching them to posts in any other user’s Patter wall, and we also made available a SAFE Toolbox that covers some basic needs developers usually face when creating SAFE apps, along with some other features explained there in detail including information about the experimental APIs.

We consider that this new version of the SAFE Browser provides a good foundation for the next steps in our journey to making the SAFE Network natively support a semantic web. This is also the reason we would strongly recommend you listen to the latest SAFE Crossroad podcast published yesterday, where @fergish does a great job in explaining the evolution of our SAFE Browser and the significance of this new release.

After researching about different libraries available for documenting JavaScript code in general, to enhance our safe_app_nodejs API documentation, we were able to publish an enhanced version of it at https://docs.maidsafe.net/safe_app_nodejs which we are generating with JSDocs with the braintree-jsdoc-template. We believe this is much nicer and cleaner which should make it easier to read and learn about the API. We’ve also made several enhancements and addition to the content of the documentation as well, e.g. adding snippets for the experimental APIs, so developers can use it if using the latest safe_app_nodejs v0.10.3 released a few days ago.

We have hit a code freeze for the release of the safe app libraries for C# and Java (Android). These libraries have a dependency on the updated SAFE Authenticator mobile application which is feature complete and is currently under testing on iOS. Once this is released, it will be followed by the release of the C# and Java packages. We are considering the release of the SAFE Authenticator application on official stores in due course.

SAFE Client Libs

This week @marcin worked on adding MutableData as a triple storage backend for the Redland library. We already converted the relevant code to Rust using c2rust, creating a redland-rs library with a working storage implementation. We are now working on modifying the code in Rust and linking it to rasqal-rs and MutableData.

Routing

The Fleming subteam continued investigating the design of the Routing code from the perspective of real-world connectivity, and large-scale network events such as restart and upgrade.

This week we consolidated our knowledge, laying out the difference between Kademlia and Disjoint Section Routing. We wrote the comparison up for knowledge sharing and so that this insight can remain in our knowledge base.

We investigated the behaviour of our current communication layer in the presence of malicious actors aiming to interrupt communication between honest nodes.

We also made good progress on distinguishing the different messaging requirements between any two nodes in the Network in a way that would allow us to decorrelate the number of members of a PARSEC consensus group with communication requirements. These ideas are still evolving, but it seems very promising as a way to ensure we can both have Sybil resilience due to large PARSEC groups while keeping realistic connection requirements by having a separate communication layer.

Finally, we progressed our understanding of the requirements for network restart and network upgrade, partly taking inspiration from other decentralised projects as mentioned last week.

The PARSEC subteam have again been focused on improving the performance and quality of the code in PARSEC. Further optimisations have been applied, again increasing the speed at which consensus is reached, while also reducing the resources consumed in doing so. Some further potential optimisations have been parked for the short-term while we focus on implementing and testing the existing ones, since the other ideas may need a fair amount of time and effort to decide whether they’re actually worthwhile or not.

We’ve also resolved an obscure bug which was recently introduced by some of the optimisation work, and which was caught during soak testing.

Crust

We finally merged the encryption changes. So everything that is put on the wire is encrypted (if you are using the Crust master branch). Then we upgraded Rust and started using 2018 edition for socket-collection and Crust crates. Rust 2018 stabilizes rustfmt and clippy tools and brings some new features which will simplify the code a bit. Eventually, we implemented bootstrap cache. The PR has gone through our rigorous review process and is almost ready

Thanks

Well that’s it for this year, the entire team really appreciate all the testing, feedback, comments and discussions you have provided during 2018. Your continued feedback is useful beyond words and it’s helping to shape the Internet of the future. We hope you get some time over the holidays (if you are lucky enough to get some time out) to spend with your loved ones and after a short break we look forward to making 2019 a year to remember!