Crate didbot_config 

The sectioned TOML file an operator edits, and its schema.

didbot-pds grew twenty-one command-line flags before this crate existed, and every epic since has added another. A flag list that long stops being a bootstrap interface: there is no way to see the shape of a deployment at a glance, and a secret cannot travel on one at all: process arguments are world-readable in /proc/<pid>/cmdline. This is the file that replaces the list.

The tier this is

docs/deployment.md names three configuration tiers by what they hold, not by what stores them: the operator’s repository holds what an agent may do — scope ceilings, admitted apps, collection permissions — and is not reachable on the host at all. Process arguments and this file are the next tier down, reachable by anyone who holds the host, and hold how the server runs: bind address, zone, state directory, which DID’s policy to read. Local state — caches, refusal records, the emergency stop — is the third.

Nothing in Config may widen what an agent may do. A scope, a permission, or an allowlist of apps has no field here, on purpose, even though a config file is the single most tempting place to let one drift in: it is right there, it is already TOML, and it is where an operator is already looking. Those stay in the operator’s own repository, per plan/policy-store.md, and are read at runtime rather than configured. sections::PolicySection is the one field this file may hold about policy at all: which DID’s repository to read, never what that repository is allowed to grant.

Unknown keys refuse startup

Every section carries #[serde(deny_unknown_fields)]. An ignored key is a setting the operator believes is in force and is not — the same fail-closed reasoning plan/policy-store.md applies to a policy version that will not validate. Config::load and Config::parse surface the offending key by name, because toml’s own deserialization error already names it.

Secrets are paths, never values

A field that names a secret holds where the secret lives, not the secret itself. check_secret_permissions checks that file’s own mode and reports — does not refuse — anything readable beyond its owner.

No section here names a secret file today, so nothing calls it: the flags it was written for went away with the shared secret they carried. sections::TlsSection::cert_source is the first field that will need it, once a path to a fixed key pair is something a run reads rather than schema. It is kept because that is a question of when, not whether, and because it is the one place this project writes down what mode a secret file must have.

It is not what keeps the secrets this project writes itself safe. Those are created 0600 under a 0700 directory by the crate that owns them, and tightened rather than trusted if they were already on disk — see didbot_pds::wal’s create_dir and open_append, and didbot-tls’s certificate store.

Precedence

precedence() is the one place the file, command-line arguments and the environment are resolved against each other: arguments win, then the file, then the environment. See its own doc for why arguments are still highest despite being the leakiest tier.

What is wired today

didbot-pds reads and applies [server], [zone], [tls], [blobs], [capacity], [names], [park], [tree], [oidc], [sessions], [credential], [intervals], [disclosure], [operator], [oauth], [relay], [writes] and [proxy].

[dns] and [policy] are schema: each names a setting whose reader lives in an epic of its own — plan/dns-providers.md for provider selection, plan/policy-store.md for which DID’s records are read as policy — and plan/config.md tracks both. A file that sets one parses and validates like any other; an unknown key anywhere in it still refuses startup.

Modules

precedence 🔒

The one place the file, command-line arguments and the environment are resolved against each other.

secret 🔒

Permission checking for the files this project’s secrets live in.

sections

One struct per [section], read from the real flag set and from didbot-serve/src/routes.rs’s constants — see the crate root for which of these a caller actually applies today.

Structs

Config

The whole file, one optional table per section.

PermissionWarning

A secret file whose permissions are wider than its owner.

Enums

ConfigError

Everything that can go wrong reading a configuration file, each naming the path it came from.

Functions

check_secret_permissions

Checks a secret file’s permissions, on Unix.

precedence

Resolves one setting across the three tiers, first Some wins.