WIP: Configuration subproblem #38
Loading…
Reference in a new issue
No description provided.
Delete branch "toonn/meta:configuration"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description of the configuration subproblem incorporating a first round of review.
@ -0,0 +13,4 @@## [Hosting Providers can update configuration][159]Hosting Providers (Hosts for short) provide part of the ApplicationShould we avoid shorthand altogether? The various terms are admittedly already potentially confusing (Does an Operator operate hardware?), User is not the same thing as "Fediversity user," which appears in issues on the fediversity repo and means Hosting Provider.
let's avoid them yes.
the term 'user' we haven't really defined tho i informally used them (which is bad) to refer to operators mostly.
to be fair tho, i think even our architecture document has used conflicting senses of 'maintainer', for one.
User is defined in the Actors section of the README.
"Fediversity user" is used in many user story issues, an example is fediversity/fediversity#158, where it means Hosting Provider, not Operator.
"Fediversity maintainer" also occurs and refers to developers of the Fediversity code where I've seen it, fediversity/fediversity#626 for example.
I'll remove the use of shorthand and switch it to "Hosting Provider" everywhere. For an architecture document that is fine but it is quite cumbersome in discussions TBH.
Should we move the Actors and Glossary sections of the Fediversity README to a glossary document in this repository? It could be a good place to mention older terminology like "Fediversity user/maintainer," which isn't a great fit for the main README. And also be a clear place to suggest future changes to terminology including shorthand.
these sound good - thanks!
The architecture document also includes Actors and Glossary sections. Is either one of these locations more recent/authoritative?
the architecture document came later, and i guess i agree the repo readme isn't really the right place. i imagine they may not have diverged too much but the readme may be more outdated.
@ -0,0 +33,4 @@setting it is possible for a new version of Mastodon to drop support. Mastodoncould handle this multiple ways:- Ignore the presence of the environment variable. The configuration wouldcontinuing from fediversity/fediversity#846 (comment):
this maybe raises the question: drop from what? as in, on the one hand perhaps drop it from the conf file used in deployment (e.g. some like
mastodon.tomlor whatever depending on the application), vs from the stored operator configuration.dropping it from the conf file used in deployment could end up more flexible in terms of potentially facilitating downgrading operator configuration across fediversity versions (if downgrades are even facilitated by the application itself given application state?).
now, if such a route were to offer more functionality, one option could be to choose that as a later extension, while settling on whatever seems easier in the shorter term.
given the potentially subjective choices involved, updating without operator involvement might just not be viable.
This should definitely go in the solution section/document. I do think the latter is easier and also a bit more declarative maybe. With the flexible approach a single Operator configuration could lead to different deployed configurations losing that declarativeness (Operator configuration and deployment configuration generator together are still declarative but the Operator only sees the former.)
Indeed, though it's easy to imagine a painless update for a small patch to an Application.
@ -0,0 +73,4 @@implicitly do through choice of Host, maybe explicit (limited) control isdesireable. Might serve as a way for Hosts to get incremental roll outs. Moreadventurous Operators are allowed to update beyond the current standarddeployment versions with the understanding that is a risk they choose to take.continuing from fediversity/fediversity#846 (comment):
separating the versions seems conceivable, sure, and i agree this could server to further empower particularly power users, perhaps.
maybe again tho i'd advocate trying to handle our enhancements in order, so as to perhaps try and keep in mind what might do for an 'MVP', rather than making things more complicated than we'd need them to be already.
dd571f0a6ftofa0b613356@ -0,0 +108,4 @@Applications offer configuration options. Some of these options are relevant toHosting Providers, others to Operators, overlap is not impossible. Stickingwith Mastodon as an example.note that our data model now does handle reconciling configurations of hosting providers and of operators at the level of a resource, which can encode any business logic needed to do this for the modeled domain.
Is this Application-specific business logic that Fediversity needs to maintain?
General policies of the form "Operators get the final say on configuration," or "Hosting Providers override Operators because the latter are expected to be non-technical," are possible and general enough that it would not be a maintenance burden.
However, it's easy to imagine more specific behavior, a domain deny-list would be a good candidate for merging rather than either party's setting to override the other, the Hosting Provider detects a spammer on some of its hosted instances and adds their domain to all hosted instances, an Operator notices abuse targeted to their instance and blocks the domain, ideally both settings are merged so all the abusers are blocked rather than having an Operator be powerless to deal with targeted abuse or the Hosting Provider to be powerless to deal with widespread, subtler attacks. Conversely a domain allow-list is sensitive, merging leads to more exposure rather than less (especially if wildcards are a thing and an Operator sets a broad default rather than leave the setting empty).
Deciding a solid policy for every option requires Application-specific information. If this is the responsibility of Fediversity we get back to a similar issue as with Fediversity-maintained schemas for upstream Applications.
@ -0,0 +119,4 @@A Hosting Provider is in a good position to spot waves of spam registrationsand to respond by enabling hCaptcha on all its Mastodon deployments or addspecific abuser domains to the `EMAIL_DOMAIN_DENYLIST`, this is a hypotheticalcase of overlap.custom interface surfaces like this raise questions on our migration story (#100) but yeah
unless our layer is unaffected for such purposes, but it feels like such decoupling maybe makes things more complicated still for now (not sure we got elegant solutions there that don't like mostly raise further questions)
@ -0,0 +139,4 @@If upstreams do not want to maintain such a schema, either the Fediversity teamneeds to maintain one or provide a way for Hosting Providers to bring their own(With a shared repository for other Hosting Providers to benefit from, aFediversity wiki?). Upstreams would be expected to provide a schema with eachtbh for the purpose of migrations between hosting providers i think the common incentive would seem to be to handle things thru a central repo rather than some wiki (fragmentation)
When I say wiki I really mean "communally managed resource without a promise of thorough validation," but that's a mouthful. A repository clearly labeled as such falls under my use of "wiki," it is harder to make it clear that such a repo is open to contributions from anyone without a burdensome review process but it can be done, e.g., the AUR or the nix-community org.
FWIW a repository doesn't solve fragmentation, different revisions will be in use due to inertia.
@ -0,0 +172,4 @@What and how can we test?- JSON schema generation:- Against a known-good module/schema pair (Characterization/Golden test).not sure such canonical pairs will exist in the wild particularly given the domain discrepancy (e.g. nix modules suggesting you to configure the
packageused)A fixed revision of a sufficiently complicated module is what I had in mind here.
@ -0,0 +4,4 @@# The overall conclusion is that Clan's usecase of generating Python types is# too different from ours.## While we have not decided to provide Conduit yet, a Matrix server is a goodfyi i think procolix promised the EC a matrix server and investigated configuring synapse, tho not sure what the status of that is since the changes in project governance.
since the start of the project i think the state of matrix implementations and their forks has kept progressing - off the top of my head the most recent decent implementation seems continuwuity.
NLNet has internally been using XMPP.
I'll rephrase to something like "While we do not plan to provide Conduit," (without yet), I didn't want to imply a value judgement in either the positive (current) or negative (do not plan sounds a bit like a decision already taken) sense here. Simply spotted a Matrix-related module while grepping Nixpkgs for a good example.
My understanding of the topic is that Synapse is the only "official" implementation, it is universally loathed because of its performance and resource use, but, the push for and optimism around Dendrite as its replacement seems to have decreased if not entirely disappeared, Conduit looked like the best (only) alternative for a while but spawned a problematic fork Conduwuit, which then spawned Continuwuity and Tuwunel, the latter seems to have its own baggage. That leaves Conduit and Continuwuity to evaluate next to Synapse.
@ -0,0 +18,4 @@# `builtins.toJSON`. Technically this is a JSON schema that allows anything,# since the subschemas in `$defs` are not referred to. Turning it into a# schema that actually restricts values is not difficult, simply add# `"$ref": "#/$defs/Input"` at the top level.yeah that's kinda what i did at my poc for forms for configuring nix contracts' providers
@ -0,0 +162,4 @@`clan-lib-jsonschema.nix` has made us reconsider.We will implement a JSON schema converter for NixOS modules on top of Nixpkgs'`nixosOptionsDoc`. To begin with it'll only contain a schema for the NixOSsounds good, i guess it sounds lower-level (doesn't seem it has a notion of JSON Schema), and maybe i managed to shoehorn two use-cases onto Clan's so far, but yeah having a tool made for more general use-cases (on top of cutting a clunky dependency) def seems an improvement.
references may be among JSON Schema's complex parts, tho not sure those are as bad in our direction here.
btw this document has maybe been a bit abstract in its criticism of clan's thing, credibly arguing it offers abstraction layers not useful to us tho ostensibly it'd offer lower-level layers of abstraction as well. as such, maybe it'd be useful to give an example of the type of module its abstraction layers (starting with high) don't handle well and argue why they wouldn't?
Hmm, I thought using a derivation to demonstrate the shortcomings would be sufficiently concrete. The problem boils down to not having all the information that can be part of module options, default values (would be nice to display in a UI) and the
readOnlyflag (options that are read-only should probably not allow modification or at least require a very explicit "I know what I'm doing," interaction) for instance.The
nixosOptionsDocoutput also has adeclarationsproperty for every option, doesn't seem too useful right now but I think it might allow pointing out an option comes from an overlay rather than upstream Nixpkgs. (Would be nice if it came with line numbers so we could easily link to the option definition for technical users. Not important if the schema's only used for non-technical UIs.)fwiw, i just got that one in for the contracts UI thing i tried there.
readOnlyi hadn't tried.fwiw
options.foo.locshould also like give[ "options" "foo" ]for in as far as that might help (i dunno if that helps the clan case).@ -7,2 +7,2 @@# While we have not decided to provide Conduit yet, a Matrix server is a good# candidate for inclusion in Fediversity and its module has options with# While we have not decided which Matrix homeserver to provide yet, Conduit is# a good candidate for inclusion in Fediversity and its module has options withso, procolix tried comparing these to set up our current instance at the time as well (synapse), and felt under the impression the older implementations seemed more mature in terms of functionality.
i'm not confident how much of that would be relevant for our purposes (still), while i think nix has also tended to make it easier to use rust/go over python (favoring... any of the 4+ implementations that aren't synapse).
those options should be included over at
apps-sheetas well, if with limited info maybe.OK, so this is just about motivating why I looked at its NixOS module at all. It holds no value judgement on what Matrix implementation Fediversity should include. I already reworded this once to make that clearer, suggestions welcome if it still isn't.
it's fine, just wanted to provide the fyi in case it was useful
c98dee72c9to82b5adc2de82b5adc2detoe9888f68f9View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.