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. Step 2 (core) built 2026-10-30 (§7); the rest not yet. Each phase stops for the org lead before the next one starts. Built after account deletion (ACCOUNT_DELETION.md), which is why it is MODULE_API 1.21.0. §4 was amended by S11-S14 (§5) when the core was built.

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, except an upload (it is shown inside a post, so hiding the post hides it)	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, unless the author is staff (S8)	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. That route is already read per viewer: it answers Cache-Control: private, no-store and varies on Cookie and Authorization, and the app sends its bearer token on public calls. (The first version of this plan said the feed was shared and cached. It is not, which is S11.)
• No blocks or per-member hides exist anywhere.

4. Design (§5 holds the decisions that shape it)

4.1 Core (website)

• Module-owned report targets (MODULE_API 1.21.0; the normative text is MODULE_API.md). api.registerReportTargets([{ id, label, snapshot, hide, unhide }]) declares the types a module's content can be reported as (for Rust: rust.chat). snapshot({ targetId, viewer }) answers what the item is for that viewer (author, text, time, where it was said), or null when it is gone or the viewer may not see it. Core answers 404 either way, so a report or a block can never confirm an item the viewer could not have seen. hide/unhide are staff's hide for everyone. Core files the report, stores the snapshot and runs the queue; the module owns the content and its hidden flag. Core's forum types are core's own and are not registered. The Integration Kit re-pins and gains a paragraph.
• Game identities (1.21.0, S12, S14). api.registerGameIdentities([{ kind, label, ownersOf }]) names the identity a module's authors are known by (Rust: steam). ownersOf(ids) answers which website account each is linked to, through the module's own links.
• One filing route for every target: POST /player/reports {targetType, targetId, reason, detail?}. Forum types keep working through the existing forum route, which calls the same model. One resolver (model/safety/targets.js) answers "what is this item, and may this reader see it" for every type, so the route needs no Team.
• 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. A module's snapshot is clipped to known fields before it is stored.
• The queue gains Hide for everyone (POST /admin/moderation/reports/:id/hide), a separate button beside the status buttons. It hides the item through its own moderation: the forum's hide (a staff row in the forum's ledger) or the module's hide. The report becomes actioned with content_reports.actioned_with = 'hide', and activity_log records moderation.report.hide. An upload cannot be hidden from here; hiding the post it is in is the act.
• Blocks: user_blocks. A row is either an account block (blocked_user_id) or a game block (module_id, identity_kind, external_id), with a display_name snapshot. A block always lands on the author's account when there is one (S12): a forum author, and a chat speaker whose identity is linked. Only an unlinked identity is blocked as itself. A game block whose identity is later linked is rewritten as an account block the next time it is read (S14). A block whose target is, or later becomes, staff stops applying and says so (S8).
• A block names an item, never a person: POST /auth/me/blocks {targetType, targetId}. The server reads who wrote it through the same resolver a report uses.
• Per-member hides: user_hidden_items (user_id, target_type, target_id, created_at). Nothing checks the item exists, so a hide cannot be used to ask whether a thread id exists in a private forum.
• Routes: GET/POST /auth/me/blocks, DELETE /auth/me/blocks/:id, GET/POST/DELETE /auth/me/hidden, DELETE /auth/me/hidden/:targetType/:targetId. OpenAPI regenerated.
• Filtering happens on the server, for every reader-specific read (S11). Signed-in forum reads drop blocked authors and hidden items, and a thread the reader hid or whose author they block answers 404. A module filters its own per-viewer feeds with ctx.safety.forViewer(userId): the reader's account blocks (S14 already applied, staff dropped), this module's own unlinked game blocks, and the reader's hides on this module's targets. ctx.safety.staffAmong(userIds) answers which accounts are staff, for a module that marks lines canBlock (S13). Neither the website nor the app holds a list of its own; each refetches after a block or a hide.
• Web UI. The forum's thread and post menus gain Hide for me and Block author, beside the existing Report. Block author is offered only where the read says canBlock (never your own, a deleted account's or a staff member's), and asks to confirm. A new Blocked section on the Account page (both /account and /admin/account) lists blocks with Unblock, says when a block no longer applies because its target is now staff, and offers Show them again for hidden items. The Reports queue shows a module item from its snapshot.

4.2 Module-Rust

• registerReportTargets([{ id: 'rust.chat', … }]) with snapshot (the speaker's name and Steam ID, the line, server, time, and the linked account if there is one; null when the viewer may not see presence on that server) and hide/unhide. registerGameIdentities([{ kind: 'steam', … }]) with ownersOf reading rust_account_links.
• 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 events endpoint filters per reader (S11) with ctx.safety.forViewer: a line is left out when its speaker's linked account is blocked, or, for an unlinked speaker, when their Steam ID is; and when the reader hid it. Signed-in readers get canBlock on each chat line (S13): false when the speaker's linked account is staff (ctx.safety.staffAmong) or is the reader.
• The live feed's chat lines gain a menu: Report, Hide for me, Block player (where canBlock), and for staff Hide for everyone. They call core's /player/reports, /auth/me/blocks and /auth/me/hidden through the shared request primitive.
• 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 is already filtered by the server (S11); the app refetches after a block or a hide and offers Block player only where the line says canBlock.

5. Further decisions (org lead, 2026-10-29)

#	Question	Answer
S6	Can a signed-out visitor report a chat line?	No. Reporting, hiding and blocking all need an account, as forum reports do today, so the queue is not open to anyone with curl. A signed-out viewer sees Sign in to report or block
S7	Can a member block a game identity (a Steam ID) that is linked to no account?	Yes (§4.1's game block). Almost everyone in a Rust chat feed is unlinked
S8	Can a member block staff?	No. The block is refused when its target is a staff account (admin, editor or moderator), or a game identity linked to one, and the menu does not offer it on staff content. A game block whose identity later links to a staff account stops applying, and Account → Blocked says why. Hide for me still works on a single staff item
S9	What does a block do to the blocked person?	Nothing beyond hiding their content from the blocker. They are not told; there are no direct messages to stop
S10	Do staff still see a chat line hidden for everyone?	Yes, marked Hidden by staff, so the hide can be checked and undone, as the forum already treats its own hidden posts

Asked while building the core (org lead, 2026-10-30):

#	Question	Answer
S11	§4.1 said the chat feed is shared and cached, so the website and the app would filter it. It is already read per viewer (§3). Filter on the server or in the clients?	On the server. The module filters its feed with ctx.safety.forViewer. No client module-API member, and the app needs no lists of its own
S12	Blocking "either one hides both" needs core to know which account a Steam ID belongs to. How?	The RunicGateway account first ("look up via username first … only if have to … linked steam id"). A block from a chat line lands on the speaker's linked account when there is one; only an unlinked speaker is blocked by Steam ID. A feed checks the speaker's linked account first and the Steam ID only for an unlinked speaker
S13	Offering Block only on non-staff lines means each line tells a signed-in member whether its speaker is linked to staff. Acceptable?	Yes. Signed-in readers get canBlock per line; signed-out readers get nothing
S14	A Steam-ID block, and the player later links that ID to an account. What happens?	It becomes an account block the next time it is read, so it then hides the account's forum posts too. If the account is staff it stops applying and Blocked says why (S8)

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), with §5's answers.

2. Core (website): §4.1, MODULE_API 1.21.0, tests, OpenAPI, BACKEND_DESIGN.md, MODULE_API.md, TEAMS.md §5.6 amended. One PR.

   Built 2026-10-30 as website feature/user-safety, with S11-S14 asked and answered on the way. Server and client suites green; the route, guard and engagement manifests and the OpenAPI spec regenerated. Walked against a throwaway database on the local MariaDB with a core on its own port and no modules: the schema ensured on boot; a player hid one post (gone from their view only); blocking a moderator's post was refused 403 staff and the read had said canBlock: false; blocking a thread's author made an account block and took the thread off the list and its link; unblock brought it back, and another account's block id answered 404; a report through /player/reports reached the queue with its snapshot; a player could not read the queue; Hide for everyone actioned the report with actionedWith: "hide" and the post was gone for members and shown to staff as hidden. S14's rewrite, and its merge when the member had also blocked the account directly, were checked against the same database. The module half (rust.chat, ctx.safety) is exercised by unit tests here and walks with step 3.

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).