Here are some of the main things to highlight this week:
- We released a new version of SAFE CLI (v0.4.0), which (among other things) adds support for adding individual files with a
- @Karamu made some screencasts to demonstrate how to use SAFE Vault, SAFE Authenticator CLI and some features of the SAFE CLI.
- @joshuef created a short video that shows how to make use of the CLI and build a site on the SAFE Network in three simple commands.
- @fergish released a podcast about Vault Phase 1 (real vault) with @nbaksalyar and @lionel.faber.
This week, we’ve got some new videos! First up are the screencasts by @Karamu, where he goes through a few CLI commands such as running a vault and connecting to the shared vault and using the safe-authenticator-cli to authorise the safe-cli application. There’s no audio but Calum has very helpfully included comments within the commands to help you follow along.
And to accompany @joshuef’s forum post the other week (Build a SAFE Site), he has created a Medium version and a short video where he shows you the CLIs in action. Do you find these helpful? We’re keen to create more tutorials to support all types of developers out there
Vaults Phase 2
Now that we have finished the planning and preparation work, we have started the implementation of Phase 2 Vaults. Remember, Phase 2 is all about running multiple Vaults: an important step that brings the ultimate goal of ‘Vaults from home’ much closer. The team has also been reinforced by @lionel.faber, @marcin, @nbaksalyar, and @yogesh, which basically brings the entire SAFE Client Libs team to work on this project.
One of the main tasks of Phase 2 is to add Routing and PARSEC to Vaults. And that’s where we start our adventure: initially, we integrate mock Routing, emulating the parts of the Routing functions we need while not directly depending on the Routing crate itself yet. This allows us to move asynchronously to the Routing team, so no team is held up. Currently, we are focusing on testing communication between multiple Vaults and ensuring all functions work as expected when we add more Vaults to a section.
In the Routing crate, work has progressed nicely on the PARSEC pruning functionality, with the first couple of PRs nearing completion. As outlined in last week’s update, the idea is to treat a pruning event similar to a prefix change where a new PARSEC instance is created and events that have not yet reached consensus are reinserted.
Today we have released a new version of the SAFE CLI (v0.4.0) which incorporates a couple of minor fixes, and only two additional features:
files addcommand: this command allows users to add a single file to an existing
FilesContainereither by providing a local file path or the XOR-URL of a file already uploaded on the network. The User Guide has been updated accordingly with information about this new command.
- Media-type (a.k.a. MIME-type) encoded in XOR-URLs: we added support for encoding the Media-type in the XOR-URLs, and with this, now all files uploaded to the network with the
safe filescommands will be linked from the
FilesContainerusing XOR-URLs which contain the file’s Media-type.
Please be aware that if using this new version of the SAFE CLI, the files/sites/XOR-URLs generated with it won’t be decodable/resolved properly by the existing PoC SAFE Browser, therefore we are preparing a new release of the PoC Browser which can handle these new XOR-URLs, and we’ll be making it available soon.
The API bindings we’ve been working on for the browser have had a fair going over this week. With Windows builds and packaging both finally working well and implemented for the CI system too. On top of this we’re working on adding a test suite too!
For those not following our Vault Phase 1 discussion on this forum, we are now trying to focus on getting the safe_auth CLI commands merged into the SAFE CLI, towards simplifying the UX for operating with the network using CLI. We are after the goal of having a single CLI where users can not only manage content, but also interact with the Authenticator. We are researching to find a way to run the Authenticator as a proper system daemon/service, which would expose an interface which any client application or Authenticator UI/GUI can interface with.
SAFE Network App
We’ve been firing in with update procedure and CI in a big way this last week. There’s been a lot of niggles to work out here to get something we’re comfortable with, but we’re zoning in on a process that’s looking good. Our first release is getting closer!
This latest UX design sprint, which is looking further past the first release, has allowed us to round out the process for buying, generating and managing account invites to the SAFE Network. This naturally has implications for things like wallets and Safecoin for the benefactor, but then the onboarding process for the recipient too.
So this is where we have spent the rest of the design sprint: onboarding new users, and in particular helping them create Identities—otherwise known as Safe IDs.
There’s more to it than meets the eye. How does a user manage multiple identities? And how might they start from a position of anonymity? And how might they want to have data, transactions, and settings accessible alongside each Safe ID?
It’s interesting and important work: to think scaled-up for the future, but then bring it back down to a manageable feature set to iterate upon.
Oh, and we’re building this set all with mobile front and centre, ready to be rapidly ported to desktop and beyond.
SAFE Desktop Browser
This last week we’ve been refining the browser proof of concept that works with the new shared vaults. We’ve added a few new tasty bits of functionality (NRS registry in the browser!? Manage sites and upload files?!?!?!) that are now working their way through QA. Once we’re satisfied there, we’ll be getting a new release of the browser out ASAP.
Other than that, with the new bindings finally working with Windows properly, we’ve at long last, been able to enable Windows tests and builds with the CI. Something that was previously impossible due to some nodejs FFI and windows incompatibilities.
SAFE Mobile Browser
As mentioned last week, we are continuing with setting up and running UI tests (locally and in CI). Until now we were dependant on the IDE to run and examine the test results, but now we can run the UI tests independently on any platform (Windows/Mac/Linux) and therefore on Azure DevOps which we are using for CI. The tests are run via Cake build scripts uses nunit-console runner to run Xamarin-UITests. We are currently able to run tests on the CI and can examine the test results published in XML format.
We also fixed an issue that was causing app crashes by checking if the session object is null before fetching content and returning the appropriate error message.
SAFE App C#
This week we actively discussed and started working on some more project restructuring and refactoring tasks so that the library is ready to use new bindings to provide APIs for the new data types and other functionalities.
We also raised a draft PR to the
safe-cli repo which includes the basic setup required to generate the native libs for desktop and mobile platform and to use the FFI bindings from
safe_app_csharp. We still have a long way to go before we release a new NuGet package with the new APIs.
SAFE Client Libs
Now that development has started for Vaults Phase 2, SAFE Client Libs has no active development. We will continue to fix any issues from Phase 1 and make improvements wherever we can, however, the team will be mostly focused on integrating routing with the Vault. See you on the other side!
This week saw continued steady progress for the BLS project, including implementing Distributed Key Generation (DKG) in mock-parsec, as well as modifying the candidate approval process to enable Adults to participate in DKG. A subtle bug related to premature consensus was also fixed in mock-parsec.
Feel free to send us translations of this Dev Update and we’ll list them here: