The SAFE Authenticator is now stable enough (with the mock network) that developers can build it (by following the instructions in the safe_browser README) and try using it with the following example applications:
- SAFE Mail Tutorial
- SAFE Hosting Manager
- Markdown Editor (web application)
Limitations:
- Deleting MutableData entries will only clear the value. See this post for more info.
- There is a file lock issue with the mock network. If the “MockVault” file is in use by the Authenticator, it’s possible that other applications won’t work as expected. The workaround will be to close the browser and then start the application again after the authorisation is successful.
- openUri doesn’t open the URL on Windows.
There will be minor updates to the MutableData API next week, with regards to the recent changes introduced in safe_client_libs.
Also, we are starting to work on some of the UI and UX aspects of SAFE Authenticator. Here are a few initial wireframes made by @Shona:
These are by no means completed, but we’d like to hear what you all think 
. If you have better ideas of ways to integrate the Authenticator into the browser, please pitch in. This is going to be the point in time where feedback can be quickly integrated.
SAFE Authenticator & API
The Authenticator and the example apps have reached a point where we would value some initial feedback. The reason for releasing these apps early is to help curious devs to take a sneak peek into the APIs and report any issues they come across. They are not as stable as they will be in the coming weeks, but we look forward to improving them with your help!
We identified a few gaps while we were testing the apps. These have been debated with the safe_core team and they are working on the issues and the feature request.
Some more news from the Java front. First though, JNR on Android doesn’t seem to be reliable and there is no concrete example to ensure that JNR works fine. @Kumar didn’t get a reply to the issue he had raised with JNR-FFI. JNI seems to work, but the work involved in creating intermediaries and managing them is certainly not easy. We also tried JNA, it does work fine with Android. We are expanding our example with JNA and testing the handling of buffers and callbacks. On a side track, we will also keep looking into the JFFI library which is used by JNR FFI and debug the issue. When JNR support is available, switching to JNR should be easy. In case anyone has prior knowledge working with native libraries on Android, please feel free to share your input.
SAFE Client Libs & Crust
There were some changes to safe_client_libs, one related to not automatically encrypting the Mutable Data key during GETs when Mutable Data is specified as private, but leave it up to the further instructions provided by the frontend. This will give Mutable Data the flexibility to have different components as encrypted or as plain text instead of strictly categorising all to be either ciphertext or plaintext. There were some build fixes as we prepared to integrate with the latest version of Rust and Clippy 0.0.128. In safe_vault, we added more reviews/comments to the Mutable Data PR. There are a bunch of test cases that need to be fixed, so work is continuing there as usual.
As explained below, we are also presently quite busy reviewing the Data Chains proposal with the Routing Design team, with many questions and solutions exchanged back and forth.
Routing & Vault
A lot of the team’s time is currently going into finalising the detailed design of the first part of Data Chains. Since we want to get this right, we are scrutinising every design decision and evaluating any possible alternatives so that when we publish it we will be confident about all of them. This involves lots of discussions and thinking through particular scenarios of message flows or potential attacks. That takes as long as it takes, but it is a crucial part of the process.
Meanwhile, the big test cleanup that was possible thanks to the fake clock has been merged, and since it also slightly extends the tests by more closely mimicking what happens in production and by simulating a wider range of sequences in which events can be handled, it already helped us to find and fix another minor bug.
Finally, work is ongoing on the node name simplification: Crust has been updated to use the same node identifier type as Routing, and soon Routing will migrate to the new Crust version and get rid of the peer ID (Crust level) vs. public ID (Routing level node identifier) distinction, simplifying the code quite a bit.
and for mobile!
thanks 
. This update wil definitely make some external devs very happy. Can’t wait to see what they come up with. Will give it a shot in the coming days to build it myself.