A secure, user-friendly web application that lowers the barrier to hosting services on Guix systems, using a Spritely Goblins agent and Bonfire-based UI.
Every day, as EU citizens, we are forced trust USA's Big Tech to hold our public digital infrastructure. We urgently need an infrastructural ecosystem that is sovereign and secure, based on open standards and trustable enough to have our most critical public services rely on it. Fortino aims to build that: with next generation technologies such as Guix, Bonfire and Spritely Goblins, a new kind of distributed orchestration platform is going to be implemented.
Compared to state of the art orchestration solutions, Fortino will be based on distributed object capabilities, allowing for finer grained access control, increasing security and preventing entire classes of misbehaviors and vulnerabilities. It will open to new scenarios and orchestration practices, as distributed capabilities have the potential to change the human processes for operating software at scale. For example they allow creating a revocable administration tokens that allow operators to perform maintenance activities without the need for them to have direct access to infrastructure or sensitive data. It could also allow offload workloads to untrusted infrastructures without hosters knowing what the workload is about and without having access to the data they are processing.
The long term goal is to bridge the distance from the Guix System to European governments, universities, no profits, and public institutions needs by implementing a sovereign orchestration layer based upon free and decentralized technologies. The expected outcome of this project is a Guile daemon exposing Guix' API through the OCapN protocol and a web frontend that is able to drive Guix systems through OCapN.
The first step would be to implement a very basic agent. The least number of functionalities required to query the current Guix configuration state and to reconfigure the system.
Then a command line UI vertical on a single application could be implemented and additional features added to the agent required to setup end to end the application. This will be a command line installer for the Bonfire project. The idea would be that the users could start with a plain Guix install, they would add the Fortino agent to their system and install the CLI installer and are able to easily install a Bonfire instance.
The next step would be a Guile Hoot library to interact with the agent from the browser; it should at least support the same set of functionality as the command line installer.
With a Webassembly interface to Fortino's agent a Bonfire framework based UI, vertical on a single application, could be implemented.
Finally Web UI support for more applications could be implemented, with a general mechanism to map Guix configuration records to UI widgets.
The core mission of Fortino is to enable groups of people, may they be institutions, cooperatives or universities to self host their critical workloads on a sovereign infrastructure. To be truly effective in today's society we need first class digital tools that are easy to use, inclusive and secure. While I deeply admire the many valuable efforts in this space - some of which are still active and serve as important reference points - this project aims to deliver a feature set that, to my knowledge, no existing project currently offers.
An extremely well known project in this space is YunoHost. Yunohost is a web application, designed to be tightly integrated with Debian, that allows non technical people to deploy end to end web applications on a single machine. In my opinion its pros are the big community and the end to end deployment experience. Its shortcomings are that: package recipes follow a different format than the one of Debian packages, so contributors have to learn yet another domain specific language with all the idiosyncrasies which come with that. Also all actions performed by Yunohost on the host system are imperative and the outcome achieved is totally dependent on the order they were taken. At last, Yunohost does not have in its scope the management of remote machines. It is designed to manage the system where it is running and nothing else, so it's really unsuitable for anyone but individuals self hosting for themselves.
Fortino's advantages over Yunohost are manyfold: there is no need to maintain an application repository on top of Guix, users can use third party channels for whatever application is not packaged in Guix mainline. Users also don't need to learn a completely new stack on top of Guix if they need to make their own application work. Fortino will support setups a-là Kubernetes where a central main node can control and configure many different nodes (which do not run the whole Fortino suite) but only an agent. Moreover, Fortino will offer all the advantages of Guix, including deriving the expected system state from a central configuration, the ability to roll back configurations and the ability to deploy configurations to remote machines.
Another player is CoopCloud, a Docker swarm based project that provides a command line utility that simplifies the provisioning and management of web applications. CoopCloud, just like Yunohost, requires an additional application repository based on OCI images on top of the native distro one, acts imperatively on the host operating system and requires packagers to learn yet another YAML flavor.
The bottom line of many of these projects is that they require the user to learn many different languages (shell scripts, TOML files, YAML files, Dockerfiles) that all describe some kind of provisioning process. This increases cognitive burden for administrators and makes it more difficult to process code written by other people to extend it or compose it. That is only possible with the kind of descriptive power that Nix and Guix implement.
There have been many efforts in creating something similar to Fortino inside NixOS, the most successful of which are SelfHostBlocks and SelfPrivacy. They satisfy different needs from the ones that Fortino is supposed to: they don't have a Web UI, assuming highly technical users that are able to write Nix code and they are not able to manage fleets of machines.
One new interesting project is clan.lol. It is very similar to Fortino in that it allows peer to peer management of fleets, but its security model is old school access control list based SSH over a peer to peer network. The advantages of using a distributed capabilities based platform such as Fortino is that access control in Fortino can be crafted on the fly, limiting access over resources in a programmatic and dynamic way, making it easier and safer to run distributed and possibly untrusted workloads.
Building on the work of existing projects, Fortino goes further in solving the following challenges:
Fortino has all the intentions of being on the best tech out there, without reinventing any kind of wheel. The most significant technical challenges faced by Fortino right now are: creating a nice UX for creating and managing capabilities, being able to remotely control Shepherd services with a fine grained RPC API and providing a nice UI/UX for the web frontend.
No active project is doing what Fortino does, this of course brings completely new challenges in terms of user experience. The dynamic nature of access control within Fortino will require a lot of thought, especially in how to empower users to control access in a fine grained manner without being overwhelming. For example, in Fortino users could craft tokens similar to SSH keys but with finer grained access control, allowing external contractors access to part of an infrastructure without giving them full access (say for example allowing to restart services without allowing to see the data running through them). This functionality would have to be exposed in a UI with a good design practice to avoid for example users giving unnecessary permissions without completely understanding the consequences of their actions.