Technical design

This page is the entry of the technical design of Fediversity. It gives the scope, the list of the parts, and links to the page that has the details of each subject. The other pages of this site, the site of the panel and the site of the API stay the source for their subjects. This page does not repeat them.

To get the technical design as one file, open the one-document page and print it from the browser.

Scope

Fediversity lets a hosting provider offer applications to its customers. These we call operator: a person or an organization that has a deployment with applications on its own domain. The glossary defines the terms and the actors.

The technical design covers five functions:

1. Install applications.
2. Configure applications.
3. Update applications.
4. Manage users.
5. Switch an operator to and from a different hosting provider.

The repository has three components, each with its own flake and its own documentation site:

api and panel use core. core does not use api or panel.

Parts of the technical design

Each page in core/docs/md/technical-design/ is one part of the technical design. The build fails when this list does not link a part.

• Access model: the persons and the components that have access to the state of the system, and the limits of that access.
• Architecture: the system context, the containers of an installation, and the components of each deployment.
• Capability flows: the run-time flow of each capability, with the code paths, the stores that change and the failure paths.
• Configuration data flow: how an operator configuration becomes a deployment.
• Contracts (RFC 189): how the contracts connect the software that needs a service to the software that gives it.
• Credentials register: where each credential is, what makes it, how long it lives and how it changes.
• Data subject requests: which party answers a request about personal data, and which mechanism the code gives for it.
• Deployment topology: the nodes of a deployment, where they run, the networks between them and the trust boundaries.
• The five functions: how the system installs, configures and updates applications, manages users, and switches an operator to a different hosting provider.
• Metering and accounting: what the system measures about a deployment, and where a hosting provider reads it.
• Logs, traces and audit records: each channel that records what the software and its users do, with its personal data, store and retention.
• Requirements of hosting providers and design review: the requirements of the hosting providers, the place in the design that answers each one, and the review of the design.
• Quality attributes: the target of each quality attribute, what the code does, and the test that shows it.
• State lifecycle: what happens to the state when the code changes, or when a service gets a new version.
• State register: each store of state, its owner, its personal data, its retention and its protection.
• Traceability of the capabilities: the requirements, the code, the tests and the docs pages of each capability.

Where to find the details