Gaia Administration Panel
Project Brief
Looking to help grow the Blockstack ecosystem? We need a Web front-end to help users set up their Gaia hubs. The app would serve as a front-end to Gaia’s new administrative API, and let the user do things like configure their Gaia hub’s backend storage settings and access controls. This is an intermediate difficulty Blockstack project.
Background
Gaia hubs are configured by means of a configuration file, as well as some environment variables. They control aspects of the hub’s behavior, such as which driver it uses (including which credentials), which public keys are allowed to write to it, and how many social proofs are required by the writer. These fields need to be configurable at runtime.
Configuring a Gaia hub at runtime today requires ssh
-ing into the hub’s host, editing the config file and environs, and restarting the Gaia hub. This is well and good for experienced developers and power users, but is not an option for everyone else. To alleviate this, Blockstack PBC created a Gaia administrative side-car – a RESTful API endpoint for reading and writing the configuration file, and instructing a co-located Gaia hub to reload itself. This paves the way for client-side tools and Web apps for administrating a Gaia hub, which makes doing so much more approachable for general audiences.
Project Requirements
The Web interface for administrating a Gaia hub could be implemented as a stand-alone Blockstack app. The challenge in doing so is that the user must be able to use this app without a functioning Gaia hub – the user may use this app to bootstrap a Gaia hub for other Blockstack apps to use.
On first page-load, the app would need to prompt the user for:
- The URL for accessing the administrative side-car
- The API key used to interact with its administrative side-car
- A password for encrypting the above information. This password should be used for encrypting all Gaia hub information stored in local storage (see below).
This information should be stored encrypted in local storage, so the user can access them in the event they cannot reach their Gaia hub.
Once the user loads in their side-car URL and API key (or provides the password to load and decrypt a saved URL and API key from local storage), the app would need to load the Gaia hub’s configuration from the administrative side-car. If the URL or API key are invalid, then the Web app should show a suitable error page indicating this.
The configuration for a Gaia hub is a JSON blob. At a minimum, the app needs to provide editable fields for each supported Gaia hub configuration field. The list of fields can be found in the Gaia hub Github repository here.
The app needs to give the user the ability to save the configuration fields and reload the Gaia hub. The app may present these as separate actions – if so, then the app should by default reload the Gaia hub whenever the user saves any changes. When the user reloads the Gaia hub, the app must test that the Gaia hub is working correctly with the new settings by attempting to store a randomly-generated file to it. If the app fails to do so, it must report to the user that the configuration changes did not take effect.
To avoid rendering the Gaia hub inaccessible if the user accidentally supplies bad configuration information, the app must store backups of the Gaia hub configuration in local storage. The app must store at least the last known-good configuration, but may store additional backups (such as the last 10 known-good configuration fields). These backups must be encrypted, since they contain sensitive information like cloud storage API credentials. The app must provide a way for the user to clear them out, since Gaia hub configurations contain sensitive information like storage system API keys.
Project Execution
Blockstack PBC has already implemented a back-end administrative side-car and test suite in the develop
branch of Gaia (code here). The side-car daemon can be used today to remotely administrate a Gaia hub via a standardized RESTful API. Blockstack PBC is also in the process of producing sample scripts, Docker files, and VM images for deploying a Gaia hub and its administrative side-car together.
What is missing is a Blockstack-powered Web app for sending commands to a Gaia hub’s administrative side-car. Since Blockstack users own their data, they should also control the means of storing it – this means giving users the ability to run and administrate their own Gaia hubs. I think building out the user interfaces for this ought to be a community-driven effort, so users have the most say in how this gets implemented.