Summary
Here are some of the main things to highlight this week:
- MaidSafeCoin will soon be on BitUniverse’s Link service. With 80% of their users based in Asia, this should hit a very different demographic from the other services that we’ve recently started using.
- We want to draw your attention to the amazing work that @happybeing is doing on his SAFE Drive project. Please go read the post, try to understand what he’s working on and if at all possible give him a hand!
- The
safe_app_javalibrary has been updated to work with the latest version of SAFE Client Libs. This is a significant milestone for the Java library as v0.9.0 of Client Libs includes fixes to the issues we have been facing in the JNI layer. - The
safe_app_csharplibrary has also been updated to work with v0.9.0 of SAFE Client Libs. Pull requests have been raised in the safe-authenticator-mobile and safe_app_csharp repositories. - The
safe_appnative lib was also upgraded to v0.9.0 in thesafe_app_nodejspackage and the last PR that is planned to be included in the next release of this package is under review and testing at the moment. - The SAFE Client Libs team has been focused on understanding which RDF capabilities we need to include in the SAFE Network core libraries to better support integration with Solid and the W3C standards.
Marketing
The push to share updates and content across a much wider range of distribution channels continues. We’ll also now be sharing our updates on BitUniverse from the launch of its Link service. The BitUniverse app is available on either iOS or Android and with 80% of their users based in Asia, this should hit a very different demographic from the other services that we’ve recently started using. The service launches on November 24th.
We’ve been spending time this week working on the distribution strategy for a variety of messages/formats/platforms, together with planning for the next piece of more substantive pieces of content around the road to SAFE-Fleming. More on this very soon. We’ve also just got our Steemit account approved (@thesafenetwork). We’re slightly stretched in terms of resources for publishing original content but we plan to experiment here a little as well over the next few weeks.
Out and about this week: @dugcampbell was at BBC Radio Scotland on Wednesday morning giving a few thoughts in the business section of the ‘Good Morning Scotland’ show and he’s also on a panel at Edinburgh Uni with three other crypto businesses on Monday 26th November, when he’ll be giving a quick 15 minute intro to the SAFE Network before debating the future of cryptocurrencies.
We’re happy to announce that @opacey has secured a venue for the London Meetup next Wednesday (28th November) at CampFire Co-working. Sign up here if you’d like to hear @nbaksalyar give a talk on Crust and discuss the recent Crust test results.
Finally, we want to draw your attention to the amazing work that @happybeing is doing on his SAFE Drive project. Not content with leading the way by collaborating with TBL’s Solid project, he’s also been working hard at building a framework that means that the vision of say a decentralised Dropbox and a decentralised GitHub on the SAFE Network are getting closer by the day. Following his recent breakthrough, this is huge news and within the team, we’re all continually amazed by the work he’s putting in. So we’ll end with a plea to everyone reading this: please go read the post, try to understand what he’s working on and if at all possible give him a hand!
Recruitment
Our new starts are all settling in well but we still have a couple of weeks yet until we can welcome our other new recruits to the company.
As for the Network Engineer role, we are still in the recruitment process for this role. We knew this would be a tough one to fill and we will get there in the end.
SAFE API & Apps
The safe_app_java library has been updated to work with the latest version of SAFE Client Libs. This is a significant milestone for the Java library as v0.9.0 of Client Libs includes fixes to the issues we have been facing in the JNI layer. We have also raised a pull request which includes code comments and automation for the generation and publishing of API documentation.
The safe_app_csharp library has also been updated to work with v0.9.0 of SAFE Client Libs. Pull requests have been raised in the safe-authenticator-mobile and safe_app_csharp repositories. As you might be aware, we have already deprecated support for x86 devices. However to improve developer experience we have decided to add support for devices with the x86_64 architecture.
The safe_app native lib was also upgraded to v0.9.0 in the safe_app_nodejs package and the last PR that is planned to be included in the next release of this package is under review and testing at the moment. We are hoping to be able to publish it in the next few days with the list of changes and enhancements made to it. The main feature for this release is the addition of all the RDF/WebIDs utilities exposed as experimental APIs.
Several fixes and functional enhancements have been implemented and already merged into the SAFE Browser repository, and we are trying to finalise the implementation of a switch in the UI which would allow users to enable the experimental APIs in the DOM as well as any experimental features we may want to expose in the browser like the existing WebID selector. We are planning to upgrade safe_app_nodejs as soon as the new version is published in the next few days, and this will lead us to a phase of exploratory testing in preparation for the next release of the browser. The safe_authenticator native library will also be upgraded in the browser to v0.9.0 in the next few days.
SAFE Client Libs
After the latest Client Libs release, we have been focused on understanding which RDF capabilities we need to include in the SAFE Network core libraries to better support integration with Solid and the W3C standards. We have started with defining the scope of the future work and we decided to base it on the mock version of SAFE Client Libs. This approach will allow us to try multiple ideas without any need to touch Vaults or Routing code, and the tests will be entirely self-contained.
Our primary goal for now is the research that should answer two important questions:
- How to store the RDF triples on the SAFE Network efficiently? There are many known ways of doing this (and the front-end team already used one of them in the safe_app_nodejs RDF emulation layer), but we’ll need to find an approach that works best while meeting the network fundamentals. This involves storing and indexing RDF triples in Mutable Data, and most importantly, storing triples in the encrypted form.
- How to implement the SPARQL query language for the SAFE Network? The Vaults will need to have some form of support for the query protocol, but it is defined with an assumption that the data is public and anyone can query it. This is not always the case on the SAFE Network, and we want to query our data without transferring any encryption keys to Vaults and compromising our security and privacy.
We already have some good ideas on how to answers these questions. We’ll be trying different ways of solving the problems and we’ll keep sharing our findings with the SAFE and Solid communities.
Routing
This week, we continued with our work on four main fronts: extending the test suite to more thoroughly test dynamic membership, performance improvements, Routing integration, and malice handling.
The work on the test suite update has been progressing steadily, and this fairly significant update should be merged to master hopefully by the end of the week. This will allow some further test tasks to be started too, since we deliberately held back on these to avoid creating extra work in needing to update new tests after this work was completed.
We completed the optimisation work as far as the easily-identifiable parts are concerned. These did, as expected, allow for the test suite to run significantly quicker, and also makes Parsec more readily usable by Routing. We also identified an issue with our proptest setup whereby it was consuming huge amounts of memory and being killed occasionally. This fix has allowed us to re-enable the proptest code, increasing the effectiveness of our soak tests once more.
Having spent some time improving benchmark tests and examining their results as part of the optimisation push, we now have a very basic process in place to help us avoid regressing badly on performance as we create new code. This setup will be given some further work in the future to make it more automated and robust.
Work has also progressed on integrating Parsec into Routing. We continue to find a wee bit of friction there at the API, and are tweaking things to suit Routing requirements while maintaining as generic an API as possible. So far, issues have been limited to missing functionality exposed by Parsec, and have been fairly trivial to address. There will doubtless be some more give and take over the coming weeks as Routing and Parsec become more closely integrated, but so far, this appears to be going well.
Finally, we have been continuing to pick off tasks which address malice detection and handling. These haven’t yielded any real surprises or problems, and we’re well on the way to completing the final few now.
Crust
We started off this week with implementing encryption in our sockets library - socket-collection. The library has to be flexible enough to fit p2p and Crust needs. Thus before merging the encryption PR, we attempted to integrate it into the p2p crate. To make sure the changes work as expected, we wrote some more tests. Then after experimenting with socket-collection and p2p, we gathered valuable insights to refine our crypto API in socket-collection.
– although thank you very much Maidsafe for highlighting my bit – but because it shows significant progress and upcoming releases in so many areas. This is brilliant.
Oooh no they got 