Summary
Here are some of the main things to highlight this week:
- @fergish interviewed @joshuef and @bochaco on the RDF/Solid connection with SAFE.
- A new version of the
safe_app_nodejspackage (v0.10.0) has been published this week on npm, which incorporates some enhancements mainly around the experimental APIs. Please refer to the changelog to see the complete list of changes. - The SAFE Client Libs team has been progressing well with the research on adding RDF/SPARQL support to SAFE Client Libs. Their progress can be tracked through the GitHub issues.
- Malice detection, testing and routing integration continue to be the main focus of the Routing team.
Marketing
Big news this week that you might have heard about - with the SAFE Network logo appearing in the new #1 US film hit, āRalph Breaks the Internetā! Props to @nigel who first spotted it and @Harvindar who got some photo evidence. Last night the story started to be picked up by the press. Weād love to find out the connection so if anyone knows, please give us a shout!
Itās been a packed week for getting out and about:
- Monday night: @dugcampbell gave a talk at Edinburgh Uni
- SAFE Crossroads Podcast: @fergish interviewed @joshuef and @bochaco on the RDF/Solid connection with SAFE
- Tuesday night: @pierrechevalier83 spoke at Rust London
- Wednesday night: @ustulation and @pierrechevalier83 spoke at the London SAFE Network meetup standing in for Nikita who was unfortunately unwell.
The rest of the week for marketing has been focused on work around messaging (more on that to come soon), producing content around Dynamic Membership in Parsec (ditto) and content strategy for the new newsletter subscription list (reminder: you can sign up in the footer at https://safenetwork.tech/). Weāve also been working at improving the video work for the weekly updates. Real progress this week and you can take a look at the improvements weāve made by checking out this unlisted video if youāre interested. We have a few further things weāre planning to do over the next couple of weeks to raise the quality even further but hopefully youāll agree that the production values are improving. Weāre keen to invest more in video updates moving forwards of various types - so the foundations weāre laying here should stand us all in good stead.
Finally, one quick reminder: SAFE Network: Brighton meetup is next Wednesday where @nbaksalyar will be running through Crust - and you can still sign up here.
SAFE API & Apps
The safe_app_java repository now includes the code comments from which the Javadocs will be generated and published. safe_app_csharp was updated to support x86_64 for Android along with the API being updated to safe_app v0.9.0. Improvements were made in handling error messages on the Mobile Authenticator. With the API stabilized and the tutorials falling in place, we are currently standardizing the project management processes, before we start planning the final testing and release process for the C# and Java APIs.
A new version of the safe_app_nodejs package (v0.10.0) has been published this week on npm, which incorporates some enhancements mainly around the experimental APIs: they are all now exposed behind a flag so developers and users can use them at an early stage, while being explicitly aware of the fact that they are still in an experimental stage. Please refer to the changelog to see the complete list of changes. The following is a summary of the highlights of this release:
- Upgrade safe_app lib to latest v0.9.0.
- Every experimental API is exposed behind a flag/option.
- XOR-URLs can be obtained for any ImmutableData and MutableData on the network.
- Experimental RDF API is also exposed which allows applications to create and manipulate data in RDF format.
- Experimental WebID API which provides an abstraction for creating/updating WebIDs on the SAFE Network, even allowing the application to publish them with a publicName āsafe://ā-URL.
- Fetch data using publicName-URLs or XOR-URLs. This functionality is supported by the āwebFetchā and āfetchā functions exposed.
We have also upgraded safe_app_nodejs to v0.10.0 and safe_authenticator lib to v0.9.0 in the SAFE Browser, which enables all the experimental APIs in the DOM API to be exposed. Weāre working on allowing users to have the control to enable/disable them for the use of web apps. We are now trying to finalise this functionality and doing a lot of exploratory testing to be able to release it soon.
Since the new version of safe_client_libs (v0.9.0) makes use of a new type of encoding (base32 as opposed to base64) for the authorisation requests/responses, we will therefore also be releasing a new version of our Web Hosting Manager application which will be compatible with the new SAFE Browser being released.
There has been a lot of work also going on around the automation of tests for the SAFE Browser, which will help us a lot to assure that changes made donāt affect the existing functionality. We are planning to keep working on enhancing this in the next few weeks, this is one of the main enhancements weāve been working on in the last months on the browser. As part of this effort, we are trying to move away from AppVeyor onto using Travis for all platforms (Windows, Linux and macOS).
SAFE Client Libs
We have been progressing well with the research on adding RDF/SPARQL support to SAFE Client Libs. Weāve started to work on Rust bindings for the open RDF C libraries, librasqal and librdf, which we want to reuse for some of the basic functions such as query parsing.
While using Rust libraries is always a better choice because of better security guarantees, we havenāt found libraries implementing the RDF standards completely, and at this point it is not feasible for us to produce them ourselves. Instead, we decided to focus on implementing basic support for SPARQL queries and triple storage on the SAFE Network as quickly as possible. Then we can start testing RDF-based apps and the ideas from RFCs proposing an RDF-based replacement for DNS. And with simple demo apps, we can iterate on these features further, providing better performance, having better API design, and more complete and seamless integration with the SAFE Network.
Our progress can be tracked through the GitHub issues.
Routing
Malice detection, testing and routing integration continue to be the main focus of the Routing team. We also had multiple interactions with the SAFE Network community and the Rust community.
On the routing-integration side, we implemented two new small API changes in Parsec to facilitate the use of this crate by routing. We are also currently looking at a third one.
One simplified the configuration of the input to the consensus protocol. Instead of giving routing the full configurability of a custom function, we now only expose a choice between a couple of options. Like any API improvement, it makes our interface harder to misuse while maintaining a sufficient amount of control over the crateās behaviour.
Another one added a method to indicate which peers are ready to receive gossip communication from a given nodeās perspective. Prior to the change, routing would just try any node it knew about until one of the communications succeeded. This approach is simpler and more expressive. It also help us make our tests more robust as we can now verify that nodes that should be able to process our communications.
Finally, we are working on a modification that allows Parsec to inform Routing when new nodes become aware of previous consensus decisions. It is not information that is essential to expose in the strict definition of a consensus algorithm, but we noticed that it would make the use of Parsec by Routing a little bit easier.
Overall, it is fair to say that we are quite excited with the progress on the Routing front, even though we are aware of more opportunities for improving the performance that might well prove necessary before we can release the network to the world 
We kept looking at various forms of Malice and systematically improving Parsec by making it able to deter nodes from engaging in these malicious activities. We implemented detection of Spam malice. Thatās when a node deliberately sends us more information than they know we need to incur extra-work for us. We also have a number of changes that should make it into master in the coming days.
We also continued to improve the testing framework and expect to merge these changes soon too.
From the community side, we were happy to merge a pull request from @u-amine on GitHub that updated our tutorial and Readme since the way we run tests and the example have changed since the tutorial was written.
@pierrechevalier83, @jonhaggblad, Andreas and @povilasb got to mingle with the Rust community by attending RustFest in Rome over the weekend. It was a great motivation boost and an instructive experience.
@pierrechevalier83 also did a presentation about the synergy between the Rust programming language and the MaidSafe values first to an audience of Rust programmers on Tuesday at the Rust London User Group Meetup, then to a SAFE Network enthusiasts audience on Wednesday at the SAFE Network London Meetup. The slides from the talk can be found on GitHub. Both talks were filmed and the videos should be available shortly.
Crust
@povilasb took 3 days off to take a trip to Rome to visit the RustFest conference and exchange ideas with fellow Rustaceans. Now back, heās been solely working on the development of socket-collection. We finally merged the encryption changes. Now different crypto contexts can be passed with socket config structure when constructing UDP or TCP sockets. Also, socket-collection now encrypts the packet header as well, which is just the packet size currently. Now at this point, all the data on the wire will seem absolutely random to the observer. We also added more UDP tests and expanded the docs. Eventually, we introduced the socket trait which will abstract TCP and UDP sockets and reduce the duplicate code.
Muhahahahhaha
Giddy inebriation is but one of the many rewards deserved and made much more enjoyable with an extended family. 
