Social LiveDocumentationPLATFORM DOCS

Safety & Moderation

Reports, moderation actions, blocking, and the enforcement surfaces.

Last updated Thu Jul 16 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

TL;DR -Users can report or block anyone; reports land in an admin queue where moderators warn, mute, suspend, or ban; a runtime keyword filter catches bad language before it's sent; and money controls (settlement holds, withdrawal review) give the safety window teeth.

Who this is for -Product, Business & Executive: the plain overview and the App Store compliance notes. Design: the report entry points. Backend & Security: the pipeline, endpoints, keyword matching, and financial interlocks. QA: the rate limits and enforcement rules.

Safety is what keeps Social Live a place people want to stay. Because rooms are live and anyone can join, the app needs both a way for users to flag problems and a way for moderators to act on them fast.

There are two lines of defense. The reactive one is reporting: any user can report a person, message, or room, and those reports flow to a moderation team who take action. The proactive one is automatic: a keyword filter blocks or masks banned words the moment someone tries to send them, and blocking lets users instantly cut off anyone they don't want to deal with. On top of that, money rules make sure a bad actor's earnings can be held while a report is reviewed.

In plain terms

  • Anyone can report a user, a message, or a room, with a reason and free-text detail.
  • Reports go to a moderation queue where staff can warn, mute, suspend, ban, or remove content.
  • Blocking cuts off messaging, calls, and visibility both ways, instantly.
  • A keyword filter blocks or stars out banned words in live chat and DMs -editable without a deploy.
  • Money is held during the safety window so a banned host can't cash out before a report is reviewed.
  • The app is 18+, enforced at signup.

The rest of this page is the mechanism behind each of these.

Reporting pipeline

Here's the path a report takes from a user's tap to an enforced outcome. Each report is stored, queued for an admin, acted on, and logged as an audit trail -not just a status flip.

Rendering diagram…
  • Client: the safety module owns the report screen; any user, message, or room can be reported with a category and free-text detail.
  • Storage: Report rows carry a ReportStatus workflow (open → reviewing → actioned/dismissed).
  • Review: the admin Reports page lists and filters the queue (badge in the sidebar shows open + reviewing counts), with per-report action forms.
  • Actions: ModerationAction rows record what was done (ModerationActionType: warnings, bans, etc.) -an audit trail, not just a state flip. User bans are enforced at the auth/service layer.

Reporting (App Store 1.2 pipeline)

This is the detailed reporting behavior built to satisfy App Store rule 1.2 for user-generated content. The key idea: the server captures a snapshot of the reported content, so moderators can still review it even after the stream ends or the message is deleted.

POST /reports persists a Report row with reason (nudity/sexual, violence, harassment, spam/scam, underage, other + free text), the reported user, and -for content reports -a server-captured snapshot (contentType: live_message | dm_message | room), so the queue can review content after the stream ends or the message is deleted. The client only points at content ids; snapshots are never client-supplied. DM-message reports verify the reporter is a conversation participant. Rate limit: 20 reports/user/day.

Entry points in the app: any profile flyout in a live room (3-dots → Report), the public profile 3-dots menu, long-press a live-chat comment (→ Report comment), long-press a peer's DM message (→ Report message).

Admin queue: /reports in the portal -filter by status, priority from reason + repeat-target count, detail page shows the content snapshot, target history, and actions (warn / mute / suspend / ban / content remove) with a moderation-action audit trail.

Developer notification (App Store 1.2): creating a report and blocking a user each emit a structured logger.warn (moderation.content_reported / moderation.user_blocked) that surfaces in log monitoring, so a moderator is alerted to review within the 24h SLA -in addition to the report landing in the admin queue.

User-level controls

Beyond reporting, users have their own tools to shape who can reach them, and hosts have tools to police their own rooms.

  • Blocking (UserBlock): blocks cut messaging, calls, and visibility both ways; managed from profile screens and enforced server-side. A block instantly removes the blocked user's content from the blocker's experience and notifies the developer (above).
  • Follow requests: private accounts approve followers, limiting audience.
  • Live room controls: hosts remove guests, and can Kick, Block or Kick & Block anyone in the room from their profile flyout's 3-dots menu -kick detaches the target from the room and bars rejoin while it stays live (see Live Rooms); ending a room kicks everyone; admin can force-end any room from the portal (end-room-button).

Chat keyword filter

This is the proactive layer: banned-word lists that screen live chat and DMs as they're typed. Admins edit the lists at runtime -no code deploy needed to react to a new problem word.

Server-side banned-word lists applied to live-room chat and DMs — the proactive layer next to the reactive reporting flow. Two lists, admin-editable at runtime (Admin portal → Settings → Chat keyword filter, or PUT /admin/settings/chat-keywords), stored in app_settings (chat_keyword_policy) with a ~10s read cache -no deploy to change:

  • Blocked terms -the send is rejected ("Message not allowed"); in live chat the comment simply never appears.
  • Masked terms -the message delivers with each match starred out.

Matching is case-insensitive, diacritic-folding, word-boundary aware (no Scunthorpe false positives), and folds basic leet-speak between letters (b4dw0rd ≙ badword). Blocked wins when both lists match. Hits are logged (sender, surface, matched term) for the moderation trail. Max 500 terms per list.

Financial safety interlocks

Safety and money are wired together on purpose: a bad actor shouldn't be able to cash out before anyone can review what they did.

Moderation and money intersect deliberately:

  • Withdrawals are admin-reviewed (see Withdrawals) -a banned or suspicious host's cash-out can be held.
  • The 72h settlement hold gives the refund/report window teeth before earnings become withdrawable.
  • Refund debt (negative wallets) marks refund abusers economically even before moderation acts; ledger metadata records refund reasons for later pattern queries.

Age gating

The platform is adults-only, checked at signup rather than trusted later.

Signup enforces 18+ via birthdate validation at OTP verification. VIP and payment features assume adult users platform-wide.