nel pedantry time
docs/general-configuration.md:7
this reads a bit wrong from what actually happens to me. the precedence order is
- env vars
- custom config file passed with --config or TRANQUIL_PDS_CONFIG
- /etc/tranquil-pds/config.toml (this is always used as a fallback even when a custom location is set)
i'd argue having the list in the reverse of the precedence order is also confusing.
this section should also mention tranquil-pds validate that can validate that config. and tranquil-pds config-template that can generate an example.toml that also includes quite a few docs.
docs/general-configuration.md:18
grammar and spelling, "the Tranqil" -> "Tranquil"
docs/general-configuration.md:32
if youre gonna mention "when using the default postgres backend" it should be further up. when using the tranquil-store backend postgres isn't used at all.
docs/general-configuration.md:42
slightly pedantic but it's not all JWTs issued by the PDS it's only session JWTs. Inter service auth JWT of course use the signing key.
docs/general-configuration.md:96
should mention that it (at least for now) defaults to [ "https://bsky.network" ]
docs/general-configuration.md:102
email should be fully optional AFAIK. you need at least one comms method configured for verification, psswd reset, etc but that method doesn't have to be email
docs/general-configuration.md:112
DKIM isn't a delivery mode. "Direct MX" is (and email.direct_mx is the core config path not email.dkim). DKIM is the signing part of that delivery mode.
docs/general-configuration.md:118
like mentioned above these three are fully fledged comms methods just like email. this section should probably be rewritten to have the four comms methods discussed one by one?
in general for general-configuration it feels a bit wordy to me? explaining some things it probably doesn't need to explain. though youre comming from a user perspective yourself here so ... probably know better.
beyond that i wanna push a little back against having this much stuff in a seperate docs thing for config specifically. the generated example.toml has quite a lot of docs for a lot of these things. and these docs live a lot closer to the actual code than seperate docs files like this do and so are much more likely to stay up to date. a balance should probably be found. and if the docs in example.toml don't explain well enough i'd argue we should improve them instead of just making another one (or at least as well as making another one)
docs/install-kubernetes.md:26
as lewis mentions i honestly quite like the "silliness" of "Go nuts with it" and i think we should keep that.
otherwise thank you! great to have a lil work in this area