Vault Phase 1 (real vault)
The final piece of the Vault Phase 1 milestone is now complete and for those who knew the DevUpdate was late, and could see the activity in GitHub know it’s been a team effort to deliver this, and so we’re beyond delighted to give this to you today 
As we mentioned last week, the final piece of this puzzle was to replace ‘mock’ vault with the real one. So now we have the CLI, SAFE Client Libs and ‘real’ vault!
We’ve created a standalone post where we give you the nitty-gritty, so head over there and join the party!!
Marketing
This week, @dirvine was speaking in the Build Track at Turing Fest 2019 in Edinburgh with a talk entitled ‘Don’t Secure The Hardware, Secure The Data: Tackling Hard But Vital Problems’. There was a really good turn out on the day and many non-crypto/mainstream technology folks in attendance - quite a different audience to the usual - to hear more about how the SAFE Network solves the problems that we all face today from a very high level.
The talk was recorded and will be released by the organisers, probably in a few weeks’ time.
SAFE Network App
The initial version of the SAFE Network App has been handed over to QA and we’re working away on fixing some bugs and stabilising the codebase across the various desktop platforms. Day by day, it’s looking sleeker, shinier, and working better. We’ve been working on updating the browser to work with the SAFE Network App, which will be able to notify of updates to applications, and trigger those updates for you too.
SAFE Desktop Browser
On the desktop side, we’ve been working on a small proof of concept, integrating with the new APIs exposed from the CLI repo. We’ve established the basic behaviour of fetch using the new Neon APIs, as well as added in some simpler helper to navigate the Perpetual Web. Right now this POC Browser is only available on Linux and macOS, though we’re working on fixing some compile issues in Windows too.
We’ve also been working on setting up the new processes for Browser releases, with auto-update requiring some changes to our setup regarding application signing and release artifacts. That’s taking shape now, so we’ll hopefully be finalising that soon enough!
SAFE Mobile Browser
We have updated the user guide section in the repo’s README to help users easily download and use the app on their mobile phones either by scanning the QR code or by using the download links for both platforms (Android & iOS).
We added a new feature in the mobile browser app for Android devices that will enable users to download images from safe:// websites to their devices. Other than that we worked on some code refactoring to keep the code uniform and simple.
SAFE Mobile Authenticator
After the last mobile authenticator release for iOS using AppCenter, community users reported that the authenticator app is not using the full screen to display content on iPad(s) and it was showing an option to zoom in/out. We figured out the reason behind this behaviour and updated the app to use the full screen. And since we were updating the app for large-screen devices, we made some changes to improve the UI for better representation.
We also updated the CI/CD process for the Authenticator app to automatically release the Android and iOS builds from the CI to the AppCenter using version change PRs.
SAFE Client Libs
Today is the big day for the SAFE Client Libs, as we are releasing a new public version of the libraries after a long time. And there’s a lot of good things that went into this release!
First of all, this release changes the architecture of the library quite significantly, while largely preserving the existing API. We don’t use Routing as a dependency anymore, and it makes the library more lightweight and easy to understand.
More importantly, now we use the new networking library and protocol that relies on QUIC, which has a number of important features, including the network traffic anonymity: because QUIC is a standard IETF protocol and is encrypted by default, the SAFE Network traffic can be disguised as the usual Internet traffic, and becomes effectively uncensorable and untraceable.
And, of course, this release of the SAFE Client Libs is fully prepared to work with the Phase 1 Vaults: it supports all the new data types (which are essential for the Perpetual Web) and implements Safecoin.
As usual, the Client Libs support two modes of operation: the first is the ‘real’ one, which uses the network connection to talk to the Vault. The second is the ‘mock’ Vault, which implements all the Vault functions within the context of your computer; it can be used for easily testing your apps without necessarily publishing them on the SAFE Network.
It provides a solid foundation for the upcoming features too. With the removal of Routing from Client Libs, it can be developed independently now, meaning that from the Clients perspective it will be easier to support further phases (including the Fleming release).
This release has a known limitation: it does not include the FFI API yet as we have decided to take more time to design it in collaboration with the front-end team. It will be included in future releases.
The new versions of SAFE App, SAFE Core, and SAFE Authenticator are published to crates.io now.
Vaults
Over the last week, we have been tweaking the Vault code and fixing the small inconsistencies we discovered after integration testing with Client Libs and SAFE CLI.
With all these things covered now, we’re happy to announce that today we released a new version of the Vault binary that you can run on your computer. It is an important release that concludes the Phase 1 work, bringing shiny new features, including the new data types and Safecoin.
And do we need to say more? You can try it yourself now!
Secure Message Delivery
We have now addressed all the big items for Secure Message Delivery. With the fixes for the Parsec consensus ordering issues (refactoring tie-breaking rules and consistent ordering when sorting interesting content) mentioned last week and additional testing, the issue of the reported failing test with real parsec as stated in issue 1734 is now resolved.
With this progress, we are now a few mandatory tasks away from completing SMD. We will want to address some of the optional tasks before completing that board. Now that this is reaching a close, we also started planning the remaining work for using real BLS keys and the DKG implemented in Parsec. A lot of the team focus has been toward planning Phase 2.
Useful Links
Feel free to send us your translation of the Update above.
Translations:
first time
Short term though I think it’s more effective to focus on people that are verified on polo already. Maybe some people in the audience thought wow this is cool and now I really want to buy some of this MAID token… then they go try to do it and realize all the hoops they have to jump and waiting involved and get turned off. Maybe not though, its just a higher bar to get non-crypto people to invest vs getting people already trading to trade our particular token.
