RunicGateway/docs
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(teams): replace the draft upload warning with the org lead's wording

Browse Source 
The drafted text was a placeholder the doc explicitly flagged as needing the org
lead's ownership. Replaced with the supplied wording, which is better in three
ways: it is factual rather than legalistic, it enumerates the specific
responsibilities being accepted (moderation, storage and backups, legal
compliance, community policy) instead of gesturing at them, and it states plainly
that RunicGateway provides no hosted storage or content moderation services.

Recorded as two surfaces rather than one, because they behave differently: a
settings help text that is always on screen and explains the setting, and a
confirmation dialog shown only when changing the mode to uploads, which is what
the acknowledgement actually records.

The dialog carries two checkboxes and the API still takes one `acknowledge: 1`.
Recording two booleans would add nothing — there is no reachable state where an
operator agreed to one clause and not the other and proceeded — while the stored
version is what answers the question that matters later: which text did they
agree to?

Three additions are proposed on top and marked as droppable, since none is
liability language and none changes what is being agreed to: that uploads are
attributed and staff-removable (the reason the attribution table exists), that
disabling uploads later does NOT delete files already uploaded, and that anyone
with forum access can upload — including manually granted accounts with no linked
game identity. Also adds the advisory `remote` mode needs, which the upload
wording correctly does not cover.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WnDSWzpUjw8t8C2hghysNz
This commit is contained in:
claude
2026-08-17 05:00:09 -05:00
parent 111b412fd5
commit f944a89660
1 changed files with 57 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
website/TEAMS.md
View File

@@ -1139,7 +1139,7 @@ decoration. One settings key does the whole job, because `settings` already stor
`updated_at` per key:
```
teams_forum_uploads_ack = "<warning text version>" e.g. "1"
teams_forum_uploads_ack = "<warning text version>" "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