Hello everyone,
TEST 5 has been running for 5 days and has proven much more stable than we had anticipated. It has been lightly used though and we would like to push this iteration a little further. There have been up to circa 80 community run nodes in addition to the 100 droplets we have deployed. It would be helpful to expand this a little over the next few days and continue to monitor activity.
There will be a new network released in line with next week’s update, it will not add much more to the core features, but will instead be more focussed on the Client components.
We should note that a very good initial RFC has been submitted for a vault RPC layer (that is something definitely in the pipeline). This will be progressed in tandem with the changes we are looking at in the client components over the next while. The RFC process will again be a focus of short term issues and longer term plans from a development perspective. It cannot be emphasised enough how vital participation in RFCs is.
App devs can now use the new version of the SAFE Launcher API (v0.5). The documentation on readme.io hasn’t been updated yet, but it will be updated soon. Please refer to the RFC in the meantime.
Today we are opening the application period for the SAFE Browser RFP. This is first RFP (Request for Proposals) of the Community Engagement Program.
The high-level requirement is relatively simple, the browser should be able to render standard web content and also enable web applications to invoke the APIs exposed by the Launcher. A mechanism to provide SAFE-only URLs as well as html…etc… is expected, whether this is default SAFE or via a “switch”. In SAFE mode we would imagine that “clearnet” requests would be blocked.
Once a proposal is added to the #development:proposals category, everyone is welcome to comment 
We are also pleased to announce that the expansion of the team is continuing with some vigour. We have a short list for the development teams having been agreed. The interviews will begin imminently. The front end team will likely be supplemented via an agency (for speed). We are also in talks with higher level advisors and will continue to seek assistance with appointments via advisory capacities and partnership opportunities.
As many of you will also have realised, we are actively pursuing additional funding routes at this time. We hope to have some welcome news in the next weeks. Our intention is to allow maximum participation whilst retaining independence. These talks are progressing very quickly and looking positive. We expect this will be a very welcome route.
Crust, Core: Andrew, Spandan (tl) & Vinicius
This week there were lots of improvements made to the FFI layer in Core. We added a streaming API which is exposed to Launcher. We also fixed some bugs in the way unwinding was handled. Destructors are now run in the correct order and panicking Rust code can no longer unwind into C/javascript code.
In Crust we migrated away from the deprecated parts of the maidsafe_utilities library to the newer maidsafe_utilities and unwrap libraries. There was also some work in fixing clippy errors and general code cleanup.
Routing, Vaults: Adam, Andreas (tl), Fraser & Qi
We added a lock file to the chunk store directories to prevent vaults from interfering with each other, and fixed a few other issues with config file and chunk store handling. Thanks to the new deterministic tests, we were also able to finally reproduce and fix a subtle routing bug that had puzzled us for a while and might in very rare cases have caused user accounts to get lost.
We’ve also been working to get sodiumoxide’s build script to actually build the native libsodium C library rather than depending on it being installed separately. This will make it simpler to compile our code and particularly to cross-compile (e.g. targeting ARM).
In the same vein, we’re working on updating another of our dependencies (brotli2-rs) which has a dependency on a C++ library. Since we want to be able to build our code using musl, and musl doesn’t provide a wrapper for g++, we need to replace the C++ library with a C one. Fortunately, much of this work has already been done by the authors of brotli. There is only a relatively small amount of work left to update the Rust bindings to match the new C library’s API.
Client: Krishna (tl), Scott & Shankar
Releasing Launcher version 0.5 was the prime focus last week. Following that, we are trying to fix the issues that were identified. A few issues were also reported by the users from the community. The fixes are getting in place and we are starting to test them. A patch update of the Launcher and Demo app is expected to be release through the course of this week.
The UI for the Launcher is being reworked and the implementation will begin this week. We are planning to add little analytics to the Launcher UI about the network activity along with some application related statistics.
Here are few Launcher mockups from @scott:
The login flow was a key consideration of ours and we really wanted to make the login as clear and simple as possible. Don’t let the mockup above fool you though, there are still three credentials (@scott was just lazy and didn’t want to animate all three! 
). We found with the old design, there wasn’t enough flexibility or space for error messages and with the three login details, there was confusion around what inputs were needed. With this redesign we sought to make this as clear as we could, and direct the user wherever possible.
.