Summary
Here are some of the main things to highlight this week:
-
@oetyng joins the team
- @dirvine spoke at the 2nd International Conference on Blockchain, Identity and Cryptography
- Latest binaries for SAFE Authenticator CLI and SAFE CLI released
- New updated POC SAFE Browser which now packages for mac and linux released
- Exciting new features in this next release of the SAFE Mobile Browser v0.2
- UI improvements to the latest Authenticator app release
- A UX bug fix and some improvements suggested by the community have been included in a new release of the SAFE Vault v0.19.2
Marketing
When did it become September?! Weāve been so busy delivering on the goods that the new month has just sneaked up upon us. Well, we can be sure September will be another epic month with even more updates for you all, as we move ever closer to Fleming.
First, weāre delighted to welcome @oetyng to the team! Youāll most likely recognise his name, as heās been a prominent member of the community for a number of years now. Heāll be initially working with @ravinderjangra on safe_app_csharp to restructure the project for future changes, looking into different solutions to provide support for the new APIs and data types, before moving across teams to provide support where needed. Weāre very pleased to have someone so passionate about the project working directly on the Network, and no doubt weāll see his efforts soon enough (no pressure 
).
While weāre on the subject of the community, itās worth reminding you of the GitHub sponsorship programme we mentioned a wee while ago. Remember, it doesnāt have to be about contributing code, you can support on documentation etc too. Please sign up, or give us a shout if there is anyone youād like to nominate and we can put their name forward.
This week, @dirvine spoke at the 2nd International Conference on Blockchain, Identity and Cryptography at Napier University. @Josh kindly shared the link here but the sound quality isnāt great, so weāll make sure we update you all with a new version if the team re-release the edited footage.
Andā¦some new content! We have the regular monthly summary for you over on Medium, giving you a helicopter view of the highlights of all we accomplished August. You know, just a few things 
!
Weāve also taken the time to pull apart last weekās Phase 1 Vaults release, taking a bit of a step back and exploring what this really means, and how it fits into the bigger path to Fleming (Medium and Forum). You guys know what to do - clap, share, comment and spread the word! This piece has been developed for a slightly less technical audience - so ideal to share with your friends and family.
And one final thing: it looks as if hardware wallet support for MaidSafeCoin may now be here via Trezor (for more details, check out this post) Warning: this is hot off the press today (h/t @sascha 
) so please be aware: we havenāt yet had a chance to investigate this so tread carefully and, as always, we advise you to carry out your own investigations before moving any coins!
SAFE CLI
As many of you already know, as part of last weekās āVault Phase 1 (real vault)ā release, we released the first packaged version of CLI, i.e. we moved from simply sharing the source code and build instructions to a proper release procedure for the CLIs artifacts.
Last weekās release triggered a nice thread of discussion about SAFE CLIs commands, existing and potential new features, found issues, UX/UI, etc. Thank you to all those who participated in these discussions - it gave us, not only a great deal of satisfaction in watching you try these things out, but also a massive amount of useful feedback and new ideas to move forward with these applications. For those who didnāt participate in it, itās never too late! Thereās a lot of nice information in the thread - come and join us.
Moreover, last weekās release and discussions kept us quite busy fixing some of the issues reported and adding some additional features which were suggested in there. This is why today we are making available a new release of both the safe_auth and safe_cli CLIs.
If you have previous versions downloaded already, you can update using the --update flag for safe-authenticator-cli or update argument for safe-cli (yep, weāve taken a note to make this consistent between the two). You can also download the new binaries from their release pages:
One of the main additions in this new release was a fantastic contribution from @draw, who implemented the auto-completion functionality for the SAFE CLI which is shared as one of the assets in the release itself. Some additional information of how to use this feature can be also obtained from @drawās original post from here.
Another feature added was the introduction of a new safe keys transfer command to the CLI (and its API) which allows users to transfer coins from a SafeKey, while the safe wallet transfer command still allows users to transfer coins from Wallets. We also made these commandsā arguments to be optional but explicit (--from and --to) moving away from the original format of being positional arguments. This allows us to support more use cases while keeping it intuitive and simple to use. The SAFE CLI User Guide was updated accordingly, if youād like to get some additional details.
Some minor additions were also included, like introducing an optional --tx-id argument to both the keys transfer and wallet transfer commands so the TX ID can be chosen by the user rather than being randomly generated by the CLI. We also added support to the cat for SafeKey URLs, which only shows information about its XOR name, if it was resolved from NRS map, etc. This can be useful particularly when a SafeKey is linked from an NRS URL, thus using cat with the --info argument/s can help us understand the NRS name resolution and location (XOR-URL) of the SafeKey.
We fixed a version number issue identified on Linux and acted on community suggestions to add a strip into the build process and include .zip and .tar.gz packages in our cli releases.
Now that this new release is ready and made available, we resumed our efforts on bringing more NodeJS bindings for the High Level APIs we are exposing from the safe_cli crate. As we saw in last weekās release, we already had a first PoC of the fetch NodeJs binding, which we demonstrated to be working with the PoC Browser fetching websites published on the Vault. We now started with trying to get the bindings for FilesContainers, Published ImmutableData and NRS APIs first, so we can eventually start exposing them on the SAFE Browser for webapps to consume.
Vaults
Following last weekās successful release of Phase 1 Vault there were some minor tweaks based on user feedback - primarily to add a -v, --verbose flag to get a better view of what a running Vault is doing. The flag can be repeated for even more verbose output. We also resolved a minor UX issue where network connectivity was required even just to display the --help menu and we updated the release process to include both .zip and tar.gz packages.
If you have already downloaded a local Vault then the next time you start/restart it, it will update to the latest version if you have a network connection. If you havenāt already downloaded a Vault to run locally then get downloading from here and be sure to read the release post from last week here.
Other than that weāve been mostly focused on planning the next phase, and how to get there as swiftly as possible. Now that we have clients able to connect to a running Vault instance and interacting with it, as if itās the whole network, the next natural step is to connect multiple Vaults in a single Section and have them coordinate their actions using PARSEC (at least for actions where maintaining a shared state is important). For some operations, like getting data, we want to do so without involving ordered consensus to make things as responsive as possible.
SAFE Network App
This week continues to involve a lot of QA for version 1, both for functionality and design aspects, as we get closer to our first release. So as well as fixing the issues raised weāve started on the next phase of the SNAPP roadmap. Initially we were focusing solely on MacOS, so for the next phase weāre aiming to resolve the installation issues on Windows too. This should then get us to the point where we can release across all three of our target desktop platforms.
Not only is the first version of the SAFE Network App getting ready to roll out, but design is already well underway for version 2.
The last design sprint for v2 was concerned with how users create an account in a permissionless way, especially on mobile devices where there will be no option to run a vault (not initially anyway).
Weāve conducted several rounds of user testing to better understand how users react to the various approaches to Account on-boarding. As is always the case with UX testing, itās very illuminating, and a couple of rounds have enabled us to hone in on specific solution to form the basis of a neatly-packaged feature set: the ability for existing Account holders to gift invites to friends, giving them all they need to get and up and running with their own SAFE Account.
Weāre now on to the business of invite generation and management.
How do existing users create, pay for, transmit, monitor andāif they have the needātake back invites? And how do we make sure they both provide enough Safecoin to meet the requirements of creating a usable Account, yet not see the benefactor overpaying, if there are currency fluctuations before an invite is redeemed? Lots of fun wee problems we are rattling through.
So this work takes in the UX design of account creation, but also the basis of how people will begin to interact with Safecoin, and pay their way on the live network, and on multiple platforms.
These are all the potted feature sets that youāll start seeing coming together on the Safe Network app, as we build out the core experience to the ecosystem.
You can expect a few screencasts on this and other elements to the user experience - after we blow the doors off the v1ā¦
SAFE Desktop Browser
After last weekās proof of concept on the new Vaults, and the issues around packaging, weāve released a new updated POC on mac and linux which now packages fine (this involved a lot of digging around both node module resolution and webpack to find the actual cause, which was in the module loading of the .node files). With this fixed, weāve been working on getting the POC branch āup to snuffā, with the aim of making this our new development base. This has involved fixing lint errors and tests across the board after we removed 30% of the codebase when removing the authentication site and libs. Weāll hopefully be merging a branch of this soon enough.
Beyond that, weāre digging into electron lib loading issues on Windows. The good news is that itās a known issue in Electron. The bad news is no single fix has made it into Neon yet, so weāre looking into what we can do here to sort out Windows packaging, so we can move onto more fun API integrationsā¦for which, weāve started a new repo which is forming a light wrapper around our rust APIs built for the CLI. This will be forming the basis of a new safe-nodejs repo, which weāre currently using for fetch in the browser.
And just a note about the documentation for the work on the Perpetual Web features of the browser: weāve decided to retire the Github repo for the time being.
Updating and managing the content of this repo during the design phase has proven to be overly cumbersome, especially alongside our design workflow in tools like Figma, and thus not terribly informative for the community.
We intend to replace this with more videos and screencasts, which seem more suited to articulating the nuances of the design decisions as things progess.
SAFE Mobile Browser
We are excited to announce the release of the SAFE Mobile Browser v0.2 . It comes with the much awaited dark mode and many other exciting features including downloading images from the SAFE site to the device, iOS navigation gestures, new progress bar based on the amount of content fetched, and some bug fixes including browsing sites with numeric addresses.
Check out the release post on the forum to download and try it on your devices (If you already have it on your device, we recommended to uninstall before downloading the latest version).
SAFE Authenticator Mobile
In addition to the new version of the mobile browser, we are also releasing a new version of the Authenticator app 
. The changes in this release are based on the community feedback. The main change is to utilize the full display on iPads. We also made some UI/UX improvements for the bigger screen Android and iOS devices.
Check out the release post on the Forum to download and try it on your devices (If you already have it on your device, we recommended to uninstall before downloading the latest version).
SAFE App C#
This week we released the safe_app_csharp NuGet package v0.2.3. In this package we have updated the safe_app and safe_authenticator native libs to the v0.9.1. This will be the last NuGet package released to support the Alpha-2 network.
We are now tackling the refactor and simplification of the safe_app_csharp project structure before we start working on the new API and data types support. This will simplify the development and build process. A massive PR was raised for the same and itās currently under review.
SAFE Client Libs
We are now on a lookout for bugs and issues reported post-launch of Phase 1, and starting to do the necessary preparation work to be ready for Phase 2. While itās unlikely to impact SAFE Client Libs in a lot of ways, weāll still need to tweak the Vault connectivity part of SAFE Core to be able to talk to multiple Vaults at once (and, as you might remember, the Phase 2 is all about having multiple Vaults!).
Because we do not use Routing to connect to the network (directly connecting to the Vaults instead), we need to have some of its functions right there in Client Libs. One of them is the handling of probable disparity between the answers that different Vaults give: some of them might be still in the process of reaching a consensus and might have a different worldview. We need to handle these cases on the client-side now, and we will be deciding what is the best possible way forward.
In parallel, options are being exercised to see which area of development will provide the most value to the roadmap. FFI is a potential area where we could be working on in the upcoming days. Weāve researched how we can proceed with interfacing SCL and NodeJS/JavaScript. One of the options is to use Neon bindings which would work similar to the Java/JNI FFI pattern.
Another area to work on would be to continue development in RDF, which was paused before Phase 1. Quicker to implement and efficient alternatives to the Redland C Libraries which provided ways to use RDF in Rust are also being looked into as many new libraries have sprung up during the paused time.
@marcin raised a PR fixing the safe_app_jni and safe_authenticator_jni sub modules in SCL which were broken during the Phase 1 changes.
Secure Message Delivery
We switched our full focus to planning the second phase of Vaults development, and planning the remaining work for the paused BLS integration project.
As a result there is only a little progress in Secure Message Delivery this week. Recently we started adding some more tests to ensure that messages are being properly secured and that invalid messages are being detected and rejected.
Useful Links
Feel free to send us your translation of the Update above!
