State register

This part lists each store of state of the software: where it is, which component owns it, whose personal data it holds, how long it keeps the data, how it is protected, and how to erase data from it. It gives the facts for the record of processing that the data protection page assigns to the operator and to the hosting provider. It is not legal advice, and it gives no legal classification.

How the register is made

The tables on this page are generated at the documentation build from two inputs:

• The declaration core/docs/md/technical-design/state-register-stores.nix. It gives, for each store, the purpose, the personal data, the retention, the encryption, the backup and the procedure to erase, with the files that these statements come from.
• The code. The build reads the databases, the buckets, the valkey namespaces and the persistentPaths that the components request, the tables that the migrations of api/ create (api/src/fediversity_api/state_migrations/versions/), and the models of the panel (panel/src/panel/models.py). The components are those of an example deployment with each application enabled.

The build compares the two inputs. The check core-docs fails when:

• an item in the code is in no store of the declaration,
• the declaration names an item or a source file that does not exist,
• a component owns no store and is not in the list of components without a store.

The check sees only the items that the code declares as data. It does not see a state directory that a module sets on a node, for example /var/lib/maddy. The declaration gives these paths by hand.

"Open" in a table means that no source in the tree gives the fact. The hosting provider finds it in its setup or in the upstream documentation, see the unknowns of the data protection page.

Which store holds which

Some stores are inside other stores. A statement about the outer store, for example its encryption, also applies to the stores inside it.

flowchart TD
  pools["Incus storage pools on the hypervisor"]
  nodes["Paths on the nodes"]
  postgresql["PostgreSQL server"]
  garage["Garage"]
  databases["Databases of the applications and the services"]
  buckets["Media and telemetry buckets"]
  backups["Backup buckets"]
  pools --> nodes
  nodes --> postgresql
  nodes --> garage
  postgresql --> databases
  garage --> buckets
  garage --> backups
  databases -- "backup" --> backups
  nodes -- "backup" --> backups

Location and owner

The column "Declared in the code" gives the items that the build found in the code for the store. The databases of the panel and of api/ and their backup buckets are not in the example deployment, thus the build does not check them.

Personal data and retention

The personal data of each log, trace and audit channel, with its readers and its controls, is in Logs, traces and audit records.

The retention settings that an operator can set for an application are in Personal data per application.

Encryption, backup and erasure

The table gives the encryption that the software adds to a store. The encryption of the disks is not in the code. The contract templates state that the disks of the hypervisors are not encrypted.

The procedures of the hosting provider are in the hosting provider guide: Know how long the backups keep personal data, Erase personal data and Know what a destroy keeps.

Components without a store

Sources