Concepts
The people Fediversity is built for and by, and the vocabulary the rest of this site uses. The option reference pages name these terms without redefining them, so this page is the one place each is spelled out.
Actors
-
Fediversity project team (maintainers)
The group developing and maintaining this project. We are creating the deployment workflows and service configurations, and curate changes proposed by contributors.
The project partners for Fediversity are:
Refer to fediversity.eu for more details about the project.
-
Developer
People with the technical background to engage with our work, and may contribute back, build on top of, remix, or feel inspired by our work to create something better.
-
Hosting provider
They provide and maintain the physical infrastructure, and run the software in this repository, through which operators interact with their deployments. Hosting providers are technical administrators for these deployments, ensuring availability and appropriate performance.
We target small- to medium-scale hosting providers with 20+ physical machines, able to scale to at least 1,000 operators.
We will provide a checklist and tips and tricks for starting new small-scale hosting providers.
-
Operator
They select the applications they want to run (so far Mastodon, Pixelfed, Matrix, ...). They don't need to own hardware or deal with operations. Operators administer their services in a non-technical fashion, e.g. as moderators. They pay the hosting provider for registering a domain name, maintaining physical resources, and monitoring deployments.
-
User
They are individuals that are not necessarily affiliated with any organisation -- they may be added by the operator, or (where enabled) may register an account on services (e.g. Mastodon) run by the operators, and e.g. post content.
The Fediversity offering is aimed at operators servicing 1 to 100 users.
Glossary
-
A collection of social networking applications that can communicate with each other using a common protocol.
-
Application
User-facing software run fully automated by the hosting provider for an operator.
Applications are the components an operator picks and configures; see Component.
-
Component
Any piece of software this project knows how to deploy: it carries a configuration module and a mapping to the resources it needs. Applications are the operator-facing components, marked
operatorFacingin the data model; the rest are the infrastructure those applications need, such as databases, object storage or a mail relay, and an operator never chooses them. -
Hosting configuration
A configuration that specifies the resources made available to deploy to, and how to access these.
-
Hosting resource
Any external entity a deployment needs, e.g. hypervisors, file systems, DNS entries, VMs or object storage instances. A component states what it needs as a
request, and the hosting provider constrains what it will hand out with apolicy; see Hosting resources. -
Configuration
A collection of settings for a piece of software.
Example: Configurations are deployed to VMs or containers.
-
Provision
Make a resource, such as a virtual machine, available for use.
-
Deploy
Put software, such as applications, onto computers. The software includes technical configuration that links the deployed components together.
-
Migrate
Move service configurations and deployment state, including user data, from one hosting provider to another.
Migrations involve service unavailability in the order of a day (due to DNS propagation) but no data loss.
-
Runtime backend
A type of digital environment one can run operating systems such as NixOS on, e.g. bare-metal, a hypervisor, or a container runtime.
-
Effect
A configurable script that interacts with hosting resources.
When such operations are stateful, these tend to use OpenTofu.
-
Deployment method
An effect that involves deploying a NixOS configuration.
-
Application instance
An instance of an Application, that an operator intends the hosting provider to host. E.g. a specific Mastodon instance behind a specific domain name.