docs/website/USER_SAFETY.md

# Report, block and hide — user safety on the website and in the app

**Status:** plan of record, 2026-10-29. Nothing built yet. Each phase stops for the org lead
before the next one starts.

**Why now.** Google Play's content-rating questionnaire for the Android app (`android/PLAN.md` M8)
was answered "users or user-generated content can be reported". The app shows other players' chat
(the Rust live feed) and has no way to report it or to stop seeing someone. Play's user-generated
content policy expects both wherever that answer is given. The org lead chose to make the answer
true rather than retake the questionnaire (S1).

## 1. What a member can do

| Action | Who | Where | Effect |
|---|---|---|---|
| **Report** | any signed-in member | a chat line (web + app), a forum thread, post or upload (web; app later, §6) | a row in the existing **Reports** queue (`TEAMS.md` §5.6). Changes nothing on its own |
| **Hide for me** | any signed-in member | the same items | that one item disappears from **their own** view, on every device. No report is filed |
| **Block** | any signed-in member | the author of any of those items | everything that author writes (chat lines and forum content) disappears from the blocker's view, on the website and in the app, on every device. Undone from *Account → Blocked* |
| **Hide for everyone** | staff (and, for their own forum, Team leaders, as today) | the Reports queue, the forum's existing moderation menu, and the item's own menu | the item disappears for everybody except staff, who see it with a *Hidden by staff* marker and can undo it |

A report and a hide are separate on purpose, as `TEAMS.md` §5.6 already says: filing a report must
never be a way to hide something. *Hide for me* is the member's own tool, and *Hide for everyone* is
staff's.

## 2. Decisions (org lead, 2026-10-29)

| # | Question | Answer |
|---|---|---|
| S1 | The questionnaire says chat is reportable, and it is not. Retake it, drop chat from the app, or add report/block? | **Add report, block and hide.** The questionnaire stays as answered |
| S2 | Where does a block live? | **On the account, everywhere.** Saved on the site against the blocker's account, so it applies on the website and in the app, on every device |
| S3 | "Hide": who hides, and from whom? | **Both.** A member can hide an item for themself, and staff can hide it for everyone |
| S4 | The app has no Teams or forum screens. Does the app get the forum? | **Plan it** (§6, `android/PLAN.md` M21). In the app, report/block/hide go on chat lines now |
| S5 | When does the Android `edge` → `main` cutover happen? | **After this feature ships**, so the first Play bundle already has it |

## 3. What exists today

- **Reports.** `content_reports` (`TEAMS.md` §5.6) is generic by design, but
  `contentReports.model.js` accepts only `team_forum_thread`, `team_forum_post` and
  `team_forum_upload`, and finds the owning Team for each. Filing is
  `POST /player/teams/:slug/forum/report`. The queue is `GET /admin/moderation/reports`, and
  `POST /admin/moderation/reports/:id/handle` claims, actions or dismisses a report. "Actioned" only
  records a decision; it does nothing to the content.
- **Staff hide in the forum.** `team_forum_moderation` already records `hide`/`unhide` (and pin,
  lock, delete) by a leader or staff, through `POST …/forum/threads/:id/moderate` and
  `…/posts/:id/moderate`.
- **Chat lines.** Each one is a `rust_events` row in Module-Rust (`kind = 'player.chat'`, with an
  `id`, `server_id`, `steam_id`, time and raw frame). The website and the app both read them from
  the public `GET /public/rust/servers/:id/events`. The app polls it signed out or in.
- **No blocks or per-member hides** exist anywhere.

## 4. Design (recommendations; §5 lists what needs an answer)

### 4.1 Core (`website`)

- **Module-owned report targets.** A new optional module hook, `reportTargets`, declares the types
  a module's content can be reported as (for Rust: `rust.chat`). Each type answers two questions for
  core: `snapshot(id)` (author, text, time, where it was said), and `hide(id, actor)` /
  `unhide(id, actor)`. Core files the report, stores the snapshot and runs the queue. The module owns
  the content and its hidden flag. This is a `MODULE_API` minor bump, **1.20.0**. The Integration
  Kit re-pins and gains a paragraph.
- **One filing route for every target**: `POST /player/reports {targetType, targetId, reason,
  detail?}`. Forum types keep working through the existing forum route, which then calls the same
  model.
- **`content_reports.snapshot JSON`**: what the item said when it was reported. Chat lines are
  pruned with the rest of `rust_events`, and a queue row must still show what was said after that.
  Forum reports fill it too, so an author editing a post after the report cannot change what staff
  read.
- **The queue gains *Hide for everyone*** beside actioned and dismissed. It calls the forum's
  existing hide or the module's `hide`, and records the report as actioned with that action named.
- **Blocks**: `user_blocks (blocker_user_id, kind 'user'|'game', blocked_user_id NULL, module_id
  NULL, external_id NULL, display_name snapshot, created_at)`. A game block names a game identity
  (for Rust, a Steam ID), because most people in chat have no site account. When that identity is
  linked to an account, blocking either one hides both.
- **Per-member hides**: `user_hidden_items (user_id, target_type, target_id, created_at)`.
- **Routes**: `GET/POST/DELETE /auth/me/blocks`, `GET/POST/DELETE /auth/me/hidden`. Their
  OpenAPI annotations and spec are regenerated as usual.
- **Filtering.** Signed-in forum reads drop blocked authors and hidden items on the server. The
  public chat feed is shared and cached, so it cannot be filtered per reader on the server. The
  website and the app filter it with the member's lists instead, read once per session and kept
  current after each block or hide. Module client chunks reach those lists through a new client
  module-API call.
- **Web UI.** The forum's thread and post menus gain *Hide for me* and *Block author*, beside the
  existing *Report*. A new *Account → Blocked* page lists blocks and undoes them.

### 4.2 Module-Rust

- `reportTargets['rust.chat']` with `snapshot` (the speaker's name and Steam ID, the line, server,
  time, and the linked account if there is one) and `hide`/`unhide`.
- **Hide for everyone** sets a flag on the `rust_events` row (`hidden_at`, `hidden_by`). The events
  endpoint leaves hidden chat lines out for everybody except staff, who get them marked.
- **The live feed's chat lines gain a menu**: *Report*, *Hide for me*, *Block player*, and for
  staff *Hide for everyone*.
- On the demo, all of this stays **open**: it is what a Play reviewer tests, and the wipe resets it.

### 4.3 Android app (chat lines only, S4)

- **Long-press a chat line** for the same menu. Report opens a sheet with the six reasons and an
  optional detail. A member who is signed out gets *Sign in to report or block*.
- **Account → Blocked** lists blocks and undoes them, mirroring the web page.
- The feed filters with the member's lists, as in §4.1.

## 5. Questions for the org lead

Each has a recommendation; nothing is built until they are answered.

1. **Signed out.** Can a signed-out visitor report a chat line? *Recommended: no.* Reporting, hiding
   and blocking all need an account, as forum reports do today. Otherwise the queue is open to
   anyone with `curl`. Play needs the mechanism to exist, not to be anonymous.
2. **Blocking someone who has no account.** Can a member block a Steam ID that is linked to nobody?
   *Recommended: yes* (§4.1's game block). Almost everyone in a Rust chat feed is unlinked.
3. **Blocking staff.** Can a member block a moderator or admin? *Recommended: yes.* A block only
   hides content from the blocker. It changes nothing about staff powers, and it doesn't stop staff
   seeing the blocker.
4. **What a block does to the blocked person.** Nothing beyond hiding, *recommended*. There are no
   direct messages to stop, and telling someone they were blocked invites the harassment the block
   was for.
5. **Staff view of hidden chat.** Do staff still see a line hidden for everyone? *Recommended: yes,
   marked*, so a hide can be checked and undone, as the forum already treats its own hidden posts.

## 6. The team forum in the app (planned, not scheduled)

The app has no Teams screens. `android/PLAN.md` M21 plans them: the member's Teams, a Team's page,
the forum's threads and posts (read, reply, new thread), the same report/hide/block menu on posts
and threads, and the forum's push stream. When it ships, the app lets members post content, so the
Play declarations gain "user-generated content: collected". M21 says so.

## 7. Build order

1. **This plan** (docs). Answers to §5 recorded here.
2. **Core** (`website`): §4.1, `MODULE_API` 1.20.0, tests, OpenAPI, `BACKEND_DESIGN.md`,
   `MODULE_API.md`, `TEAMS.md` §5.6 amended. One PR.
3. **Module-Rust** (`edge`): §4.2 plus the core-ref pin. One PR. **Integration-kit**: the re-pin and
   a paragraph on `reportTargets`. One PR.
4. **Android** (`edge`): §4.3. One PR.
5. **A walk** on the demo after the next wipe: report, hide and block, each on the web and in the
   app; *Hide for everyone* from the queue; a blocked Steam ID that later links to an account stays
   blocked.
6. Then `android/PLAN.md` M8's cutover (S5).