Summary
Here are some of the main things to highlight this week:
- The next SAFE Network: Brighton Meetup will be on Thursday, March 14.
- A new version of the SAFE Browser was released yesterday.
Marketing
Another week of building up knowledge and materials on top of the usual daily business-as-usual for the Marketing Team. Ultimately this work will translate into documentation that fills some of the existing gaps in explaining the existing (and coming) tech for newcomers to the project. In addition, the next SAFE Network: Brighton Meetup is now arranged for Thursday, March 14: @dugcampbell will be giving a general introduction to the SAFE Network slanted towards a non-tech audience before @bart calls in via video and gives an update on PARSEC that youāll not want to miss!
SAFE API & Apps
Over the last few days, @vigneshwara has been gunning down tasks in the safe_app_java milestone. The unit tests now demonstrate additional scenarios such as sharing of mutable data, manipulation of permissions, etc. Developers can use these unit tests as API usage reference while building applications of their own. We have also completed integration with coveralls.io for code coverage. Additionally, with some help from community member @ogrebgr we are also exploring a new route for the packaging and distribution of the Java desktop library.
We are working on project scope documentation of all the C# repositories which will help community developers to understand the scope and structure of different projects. The documentation will also be helpful for new contributors bootstrapping on the various projects. Also, we are wrapping up the UI/UX improvement milestone for the SAFE Authenticator mobile app.
A new version of the SAFE Browser was released, containing a number of small fixes and enhancements. Read the changelog for more details.
Recently weāve started some exploratory tasks looking at the possibility of having some form of CLI for some of the most common and/or most used features available to end users and client apps. For example, developers creating desktop SAFE apps need the Authenticator and Browser running to be able to authorise an app and test it, thus we are starting to look at how a simple Authenticator CLI could help in this regard. We are in the very early stages of such research and depending on how this evolves we will be sharing more details and plans for it.
SAFE Client Libs
We are continuing to make good progress on adding RDF stack support to SAFE Client Libs. This week we solved a blocker in the proof-of-concept project for Mutable Data based triple storage implementation. We are considering taking a bit simpler approach in integration with Redland (a standard-conforming RDF library written in C), utilising the existing code and making a number of required changes minimal for the first iteration. Once this problem is solved, we should be able to start using SPARQL queries on the triples stored on the network, making it a new way of consuming and analysing data on the SAFE Network. We will provide more interesting use cases and examples soon, demonstrating why native Linked Data support in the Client Libs is important.
This week weāre also preparing to publish the draft of the first RFC on RDF on SAFE to start a public discussion. This RFC defines RDF support in a more broad and abstract sense, proposing an API and listing the benefits it brings to our development stack and the network in general.
We also continued reviewing and publishing our documentation to the Client Libs wiki. Weāve updated the Readme to make it less verbose, linking to the wiki to save on space and to be less overwhelming to newcomers. We moved our safe_core module-level documentation to the wiki as well (though the docs.rs page will not be updated until we do a version publish).
Weāre continuing to work on the comprehensive documentation for Client Libs. Note, however, that for the time being the wiki is still being worked on, and some links to other pages may not work yet ā please be patient while we continue publishing all of our docs. As a bonus, @marcin took some time this weekend to create a nice overview of how all of our crates fit together 
Routing
Continuing on from last week weāve been further focusing the scope and features of Fleming, aided by the simulations and probability modeling for Sybil attacks and message delivery. We have a few alternatives for reliable message delivery that weāre weighing up the pros and cons of and we expect to enter a phase soon where some of these will be made more concrete in code.
The updated Parsec whitepaper is nearing completion. It improves the algorithm to make it fully asynchronous using threshold cryptography. As explained earlier, the updated whitepaper wonāt result in an immediate change in the implementation as we are prioritising features that are must-haves for the release of SAFE Fleming. In the meantime, we are drafting an RFC to capture all the knowledge gained when looking at the implementation closely a couple of weeks ago.
The ongoing performance optimisations for Parsec is still a priority and is progressing nicely, with both algorithmic and implementation improvements. A few changes that are in the pipeline increase the bandwidth of the algorithm significantly, especially when membership changes are less frequent than other events; which we think will be a realistic scenario in a live network. The main idea is to bundle together multiple opaque payloads inside single gossip events so that the bandwidth isnāt limited by the CPU cost of processing a given gossip graph. Fundamentally, this allows us to have a configurable trade-off between throughput and latency. We are still preparing these changes for integration into the codebase. Once they are integrated, we think we may be approaching the point where we believe the scalability to be sufficient, prior to gaining more data by running actual test networks.
Crust
As we continue to move toward Fleming, we are currently focusing on detailing the requirements to enable dynamic connections (and the API changes), which will allow Crust to scale up to thousands of connections. We are almost ready to start drafting the RFCs to bring in wider engagement and discussion.
In addition, we simplified bootstrap cache and we believe we made it more robust at the same time. So now if cached peers are inactive for a prolonged time, they wonāt be kicked out of the cache because they might become alive in a short time again. The only time peers will be evicted from the cache is when it is full and we want to cache new peers that we definitely know are connectible.
. But keep focused and meet goals and note the improvements and new good features thoughts up in some github issues/project board for later review and implementation.