Last week, we added this tutorial to the SAFE Dev Forum:
It explains how to build the SAFE Browser with Mock-Vault and how to upload a website using the SAFE Hosting Manager app. We are also planning to add a few code examples that will help you understand how to use the SAFE Browser DOM APIs to build dynamic web applications. We are having some issues with some of the code examples, so you’ll have to wait a little longer for those, but we’re happy to have this one for you to play with. We’ll update this tutorial with more code examples once we resolve these issues. 
SAFE Authenticator & API
safe_app_nodejs has been updated to work with the latest dev branch of safe_client_libs. The error strings are now propagated across the FFI boundary and the inconsistency of calling the encryptKey function has been fixed. For Private MutableData, it now becomes the responsibility of the application to encrypt the keys and values depending on the use case.
The Authenticator was also updated to work with the latest safe_client_libs dev branch. Based on the feedback from last week, some devs had to manually clear the beaker-plugin-* modules from the app/node_modules directory and build safe_browser again. The build scripts have now been updated to address these issues. Thanks to all the community members who have tried building the apps (@southside, @JPL, @happybeing, @draw, @maxweng, to name a few). Fetching index.html as the default file, auto redirection to the safe: protocol and a DOM API fix for the quickSetup function of MutableData are now implemented in the SAFE Browser.
A few approaches on how to distribute the Java API for desktop and Android were tried. We are planning to distribute an AAR file for Android which can be configured as a Gradle dependency in Android Studio and used by devs. The safe_app native library for each architecture will be packaged within the AAR file itself. On the other hand for desktop applications, the devs can include the JAR as a Maven dependency. When the JAR is downloaded, the native library is downloaded based on the platform and architecture as part of the post-install script.
The examples in the documentation might not be up-to-date. However, devs can make use of the test cases in safe_app_nodejs for reference. We will review and get the examples in the documentation verified and updated.
SAFE Client Libs & Crust
The uTP API has now been finalised by Carl and the library is ready to be used and tested. So we will soon be planning to integrate Crust with uTP support, which of course includes UDP hole punching. This should certainly help us connect to more peers and reduce tunnels. We will investigate different approaches since the uTP crates design choices affect the way Crust is currently designed with its state machine paradigm, and then subsequently come up with tasks to implement it.
We ported a mechanism from the master branch of safe_vault to the MutableData PR which queues the data chunks that a new node needs to store, and schedules their transfer, instead of requesting them all at once. That is slightly more complicated code, but necessary to make safe_vault scale to large amounts of data.
Mutable Data has individual entries which can be mutated independently of each other unlike Structured Data. So we are looking into the optimal way to refresh this, otherwise a refresh message per entry could lead to more bandwidth during churn.
Routing & Vault
Regarding the first part of data chains, we are still having several active threads of discussion, and doing research in different directions. In a complex system like this one there are a lot of design choices to make and we are trying to strike the right balance between reinventing the wheel and settling for an efficient solution.
Work on the node name simplification is also progressing well, but still ongoing, we hope to have the back of this one broken late this week or early next week.
Here to halp
i have to fix a Lot (!) of stuff right now … if you are too fast i might have problems to focus on my work … :-\ 
), but it would be nice if existing coins could just be planted as seeds in MutableData. There will be more farmers than miners, who gives a dawn about a blockchain when all you want to do is transfer money.
Burn baby burn