diff --git a/website/TEAMS.md b/website/TEAMS.md index 43da912..a26760a 100644 --- a/website/TEAMS.md +++ b/website/TEAMS.md @@ -1139,7 +1139,7 @@ decoration. One settings key does the whole job, because `settings` already stor `updated_at` per key: ``` -teams_forum_uploads_ack = "" e.g. "1" +teams_forum_uploads_ack = "" "1" — the wording in §5.5.5 → updated_by = the admin who acknowledged (existing column) → updated_at = when (existing column) ``` @@ -1158,20 +1158,66 @@ honouring a stale acknowledgement forever defeats versioning. So: **uploads keep persistent admin banner requires re-acknowledgement, and **no other forum setting may be saved until it is given**. Non-destructive, and impossible to ignore. -**Draft warning text — the org lead should own the final wording.** This is liability language for -the project, not something to settle in a design doc; it is drafted here so the mechanism can be -built against something real: +**The wording, version 1** — supplied by the org lead 2026-08-17 and normative for the build. It is +**two surfaces, not one**, and the split matters: the first is always on screen and explains what the +setting is, the second appears only at the moment of change and is what the acknowledgement records. -> **Enabling uploads means your community can store files on your server.** +**(a) Settings help text** — rendered beneath the image-mode selector at all times, in every mode: + +> Image uploads are disabled by default. > -> Runic Gateway is software you are running yourself. The Runic Gateway project has no access to, -> control over, or responsibility for any material your community uploads to your server. You — the -> operator of this deployment — are solely responsible for what is stored and served from it, -> including moderating it and complying with the law in your jurisdiction. +> Enabling uploads allows users to store files on infrastructure that you control. > -> Uploads are attributed to the account that made them and can be removed by your staff at any time. +> By enabling this feature, you acknowledge that you are responsible for: > -> ☐ I understand and accept responsibility for material uploaded to this server. +> - Moderating uploaded content +> - Managing storage and backups +> - Complying with applicable laws and regulations +> - Establishing policies for your community +> +> RunicGateway does not provide hosted storage or content moderation services. All uploaded content +> is stored on your own infrastructure. + +**(b) Confirmation dialog** — shown only when changing the mode *to* `uploads`: + +> ⚠ Image uploads are currently disabled. +> +> Enabling uploads will allow users to store files on your server. +> +> ☐ I understand that uploaded files will be stored on infrastructure that I control. +> ☐ I understand that I am responsible for community moderation policies on this installation. +> +> `Cancel` · `Enable uploads` + +**Two checkboxes, one recorded acknowledgement.** `Enable uploads` stays disabled until both are +ticked, but the request still carries a single `acknowledge: 1` and the stored value is still the +text **version**. Recording two booleans would add nothing — there is no reachable state where an +operator consented to one clause and not the other and proceeded anyway — while the version is what +actually answers the question that matters later: *which text did they agree to?* + +**Three additions proposed on top, marked so they can be dropped.** Each closes a gap the text above +does not currently cover; none is liability language, so none changes what is being agreed to: + +1. **In the help text, after the bullets** — the reassuring counterpart, and the reason §5.5.4's + attribution table exists at all: + > Uploads are attributed to the account that made them, and your staff can remove them at any time. +2. **In the dialog** — the expectation gap most likely to bite. An operator who turns uploads off + because of a problem will assume the problem goes with it, and it does not: + > Disabling uploads later stops new files being accepted. It does not delete files already + > uploaded — remove those from the forum moderation tools. +3. **In the help text** — the blast radius, since "users" is doing a lot of work. Forum access is not + the same as game membership (§2.5 path 3), so this genuinely surprises: + > Anyone with access to a team forum can upload, including members granted access manually who have + > no linked game account. + +**Not covered by this text, and needing its own line: `remote` mode.** The wording above is +upload-specific, and correctly so — nothing is stored in `remote` mode, which is why it takes a +non-blocking advisory rather than an acknowledgement. It still needs one, because the operator's +server is doing the displaying: + +> Images hosted elsewhere are loaded by each visitor's browser directly from the site hosting them. +> That site can see your visitors' IP addresses, and you do not control whether the image changes or +> disappears. #### 5.5.6 Publication