Summary
Here are some of the main things to highlight this week:
- Yesterday, we announced on Medium that we’re releasing support for developers to build native Android SAFE apps. More details on this release are available in this forum post.
- Today, we shared our thoughts on what 2018 meant for the SAFE Network on Medium.
- Most of our crates have been updated to use the Rust 2018 edition.
Marketing
The Marketing Team are back and can’t wait to get stuck into 2019! Since the last Dev Update, we’ve been knee-deep in planning out the coming months, working on the release for Android developers, sharing our thoughts on what 2018 meant for the SAFE Network on Medium (all claps gratefully received!) and generally getting the work arranged amongst the growing team. In the coming week, @dugcampbell will be on Ernest Hancock’s ‘Declare Your Independence Show’ tomorrow and he’ll be doing an interview with the CryptoBeadles YouTube channel early next week also.
Recruitment
We are still on the lookout for a Network Engineer, more information can be found here - Join the Team | MaidSafe
If you know of anyone with the experience required please send them our way (careers@maidsafe.net) 
QA
During the second half of the Christmas week, @pierrechevalier83 and @marcin took the opportunity to begin upgrading the Rust compiler version used in all of our Rust repos. Most of our crates are now on Rust stable (with the exception of SAFE Client Libs, which we are working on), meaning that we will no longer require an exact Rust version. “stable” will always keep our crates up to date on the latest version of the compiler, leading to less frequent compiler updates. The stable version also now supports clippy, Rust’s code linting tool, and rustfmt, Rust’s code formatter, so we were able to remove the nightly compiler from our build processes, as nightly was only needed previously for clippy and rustfmt. In addition, we moved most of our crates (apart from SCL, which is in progress) to use the 2018 edition of Rust.
We also considered the implications of moving to using MUSL builds throughout the Rust side for better support and reproducibility across Linux distributions. We had already merged a test PR for this for config_file_handler when we discovered that there is a lack of support for dynamic MUSL targets in rustc. From here:
There are still some rough edges with dynamic musl - it’s essentially a tier 3 platform and there are possible issues with backwards compatibility
As we currently mostly have static builds (SAFE Client Libs being a notable exception), we may still proceed with the plan to build with MUSL for static binaries throughout the backend, but not for dynamic libraries.
User Experience
The UX team continue to research user needs with a view to improving the UX of the SAFE Network.
Additionally, as part of its ongoing evolution, we have started planning the next version of the safenetwork.tech website to include UX and design enhancements. So thanks to everyone who took the time to give feedback on the latest version!
SAFE API & Apps
After the big browser update before Christmas, we’re now working away at smaller bugfixes with a view to producing more frequent browser releases going forwards. Over the festive period, we fixed some tabbing issues, added more testing, worked on some reconnectivity problems and tried to bend Travis’ Windows beta CI to our will (as well as some other smaller bugfixes, too).
Alongside the browser maintenance, there’s been some further exploration of RDF tooling, and usage of XOR-URLs. And while we’ve nothing concrete to show yet, we’ve fired into some initial draft functionality using the RDF setup described in the RDF / PublicName RFC.
Yesterday we had the first ever release of the safe-app-android and safe-app-android-dev packages. 
With these packages, developers can now develop native Android applications using Java/Kotlin. Along with these we also released a tutorial application which demonstrates their usage and a step-by-step guide to get development started, available on the DevHub. We also released an updated safe-authenticator-mobile POC which uses the latest APIs to authenticate users on the network.
SAFE Client Libs
This week we started making a concerted effort to document the libraries, both on a high-level for newcomers to the codebase as well as on a lower-level to track the details and moving parts. Most of the documentation is internal for now while we review it and think about how best to share it, whether it be in READMEs, module-level documentation, or otherwise. However, we did already move one of our internal pages, “Building from Source”, to the SAFE Client Libs README, and people can benefit from it right away.
Routing
The Fleming subteam have continued their investigations and discussions into the big questions remaining for the network.
Much of the focus this week has been on network restarts… how to retain the notion of trust in the event of a full restart of the network. There are various ideas being progressed, and there appear to be many factors which overlap with other requirements; for example vault upgrades, re-establishing trusted connections and state we‘d have to preserve currently outside the chain…
Work has also continued on PARSEC, with a few bugfix PRs having been written, reviewed and merged this week. We’ll be continuing to keep an eye on performance, with some thought going into further optimisations, but with the main focus shifting back to picking off more of the tasks related to handling malicious node behaviour.
Crust
This week we spent a considerable amount of time in changing the external reachability test semantics. Currently, we allow Vaults to connect to the network only if other people can reach them via an external IP address. Hence Crust executes the external reachability test before finishing a Vault connection.
We made this test more reliable and secure: First, it was easy to bypass this test, because the connecting peer was nicely asking to execute the test. From now on the connection listener will always check the external reachability. Although, this behavior can be disabled via a special function Service::set_ext_reachability_test(false) when needed.
In addition, the external reachability test is now executed during Service::connect() as well instead of only during connection bootstrapping. And finally, the test itself was changed from a simple TCP connectivity test to an encrypted Crust request/response scheme that ensures the external endpoint is actually Crust, not some random service running on the Internet.
We are also glad to see some extremely helpful community engagement who not only identified an issue with our example applications, but also stepped in and fixed it! Kudos to you guys 
To encourage you to keep playing with Crust, we’ve added some documentation on how to use the example.
I wish you the SAFE Network to go first, as it deserves! 
