hosting provider may configure thru a front-end #1333

New issue

Open

opened 2026-08-10 22:17:21 +02:00 by kiara · 0 comments

kiara commented

2026-08-10 22:17:21 +02:00

Owner

As a hosting provider,
I want a front-end to help me configure my environment,
so that I may be guided to make informed choices without having to have too much knowledge of Fediversity internals.

implementation notes

right now, hosting providers are expected to settle for examples/hosting-config.{nix,toml,json}, while they may similarly prefer a more visual interface - which as per our panel we should already largely have.
if we have schemas underlying the format (also see data model, tho we should recheck if that's the entity of this format), as would be needed for such a front-end, this might be useful for say LSPs as well
while the configuration files make it explicit which values are set and may be pruned, if they were to visually configure this, we would need to distinguish "leave this value to the operator" vs "accept the option's default value and prune it from the options the operator may configure"
visually set configuration would need migrating across versions (#629) just like when an operator does this. as in that case, pinning to the default value should probably delegate migrations to changes in the default value.
potential follow-ups:
- there may also be a demand to set a different default without pruning the option from the operator configuration
- settings relevant to both operators and hosting providers (see #627)

**As** a hosting provider, **I want** a front-end to help me configure my environment, **so that** I may be guided to make informed choices without having to have too much knowledge of Fediversity internals. ### implementation notes - right now, hosting providers are expected to settle for `examples/hosting-config.{nix,toml,json}`, while they may similarly prefer a more visual interface - which as per our panel we should already largely have. - if we have schemas underlying the format (also see [data model](https://core.pages.git.fediversity.eu/data-model.html), tho we should recheck if that's the entity of this format), as would be needed for such a front-end, this might be useful for say LSPs as well - while the configuration files make it explicit which values are set and may be pruned, if they were to visually configure this, we would need to distinguish "leave this value to the operator" vs "accept the option's default value and prune it from the options the operator may configure" - visually set configuration would need migrating across versions (#629) just like when an operator does this. as in that case, pinning to the default value should probably delegate migrations to changes in the default value. - potential follow-ups: - there may also be a demand to set a different default without pruning the option from the operator configuration - settings relevant to both operators and hosting providers (see #627)

Rows
Columns