[spike] unifying option sets #1279

New issue

Open

opened 2026-08-04 13:01:29 +02:00 by kiara · 0 comments

kiara commented

2026-08-04 13:01:29 +02:00

Owner

currently, our data model revolves around routing options to the right audience (between hosting providers vs operators), while as noted in #1209 (comment) since #1071 we actually use this hybrid model where frontend-exposed options, originally deemed operator-facing, now blurred toward technically allowing hosting providers to configure upfront as well (in which case they would no longer be exposed to operators anymore).

while this generalized our model to an extent, it raises the questions on whether we could take that further:

could such a hybrid mechanism cover our option set currently explicitly deemed hosting-provider-facing (see examples/) as well?
would our data model still hold relevance under such a unification? what might hold, and what could be generalized?

currently, our [data model](https://git.fediversity.eu/fediversity/meta/src/branch/main/architecture-docs/architecture.md#configuration-data-flow) revolves around routing options to the right audience (between hosting providers vs operators), while as noted in https://git.fediversity.eu/fediversity/fediversity/issues/1209#issuecomment-18294 since #1071 we actually use this hybrid model where frontend-exposed options, originally deemed operator-facing, now blurred toward technically allowing hosting providers to configure upfront as well (in which case they would no longer be exposed to operators anymore). while this generalized our model to an extent, it raises the questions on whether we could take that further: - could such a hybrid mechanism cover our option set currently explicitly deemed hosting-provider-facing (see `examples/`) as well? - would our data model still hold relevance under such a unification? what might hold, and what could be generalized?

Rows
Columns