Moderation & Safety

1. Automated Text Moderation

Every block of user-generated text on FUSE — chat messages, profile bios, and event descriptions — is scanned before it is saved. The text moderation layer is defined in lib/content-moderation.js and is backed by two operator-editable database tables created in migrations/0008_text_moderation_lists.sql:

• moderation_blocklist_terms — a list of prohibited keywords with a block / flag severity. The table is seeded with the same profanity terms that ship in the code and can be edited at runtime by operators without a deploy.
• moderation_regex_patterns — a numbered set of regex patterns with a named handle and a severity. The seeded entries are: phone_e164, phone_simple, email, social_url, and generic_url. Together they catch attempts to share phone numbers, email addresses, and external social profiles — the kind of off-platform pivot that scammers use to bypass in-app safety controls.

Both lists are loaded by loadModerationLists() and held in a process-local cache with a 60-second TTL (configurable via MODERATION_CACHE_MS). The moderated entry points are:

• Chat messages — POST /api/messages in routes/messages.js. The trimmed content is run through moderateText(); on a flag the user is marked is_flagged with field message and reason term:<word> or regex:<name>, and the request is rejected with HTTP 422.
• Profile bios — PATCH /api/profile in routes/profile.js. Same flow with field bio.
• Event descriptions — POST /api/events in routes/events.js. Same flow with field event_description.

The text-moderation layer is fail-open: if the database lookup or regex compilation fails for any reason, the layer logs a warning and returns { flagged: false } so a transient moderation outage cannot prevent users from sending messages. Failures are visible in the logs and do not silently bypass policy.

2. Automated Photo Moderation

Every avatar uploaded to FUSE is sent through an automated image-moderation check before it reaches the user's profile. The flow is in lib/content-moderation.js (moderatePhoto()):

• The raw image bytes are sent to AWS Rekognition's DetectModerationLabelsCommand with MinConfidence: 70. Rekognition is the only photo-moderation provider we integrate.
• The photo is flagged if Rekognition reports an Explicit Nudity parent label, or a top-level label of Sexual Activity, Graphic Violence, or Hate Symbols. These four categories correspond to rekognition's policy-violation taxonomy and align with the App Store Guidelines for user-generated content.
• Only the image bytes go to the moderation provider. Profile text, location, and account metadata are not transmitted to the moderation service.

Photo moderation is invoked from POST /api/profile/avatar in routes/profile.js. On a flag, the user is marked is_flagged with field avatar, the upload is rejected with HTTP 422, and the photo never reaches storage.

Like the text layer, photo moderation is fail-open when the provider is not configured: if MODERATION_PROVIDER is not set to rekognition, or the AWS credentials are missing, moderatePhoto() returns { flagged: false } and uploads proceed. The provider is also fail-open inside the try/catch around the AWS call: a Rekognition network error logs a warning and returns { flagged: false } rather than blocking uploads system-wide.

3. User Reports & The Admin Action Panel

Users can report another user from inside the app. The reporting endpoint is POST /api/reports in routes/reports.js, and every report must carry one of four reasons:

• harassment
• spam
• inappropriate_content
• other

Self-reports and reporter-mismatch attempts are rejected at the route level (HTTP 400 and HTTP 403 respectively) so the queue is reserved for genuine signal. The persisted report schema (reporter, target, reason, context, status, reviewer attribution, and resolution note) is defined in migrations/0006_reports.sql and extended in migrations/0009_report_moderation.sql.

Trust & Safety reviewers work from an admin-only queue and action panel:

• GET /api/admin/moderation?status=pending — paginated queue of open reports. Returns reporter, target (name, email, bio, avatar, flagged state), reason, and context. Mounted in server.js as /api/admin/moderation and gated by requireAuth + requireAdmin.
• POST /api/admin/moderations/:id/review — accepts an approved or removed decision and an optional resolution note. Mounted under /api/admin/moderations in server.js. Logic in routes/admin-moderation.js.

A remove decision does more than close the report: it calls setUserFlagged(targetId, { field: 'review', reason: note }), which sets users.is_flagged, users.flagged_field, and users.flagged_reason in a single transaction. Flagged users are then gated out of the feed, swipes, matches, and messages by the requireOnboarding middleware in routes/auth.js.

The same moderation surface is available inside the app for admin users via the in-app #moderation view in public/app.html, which renders the queue and the two-decision action panel.

4. 17+ Age Verification

FUSE carries the App Store age rating of 17+. The minimum age is a single source of truth: MIN_AGE = 17 in lib/age.js. All age gating reads from that constant.

The gate is enforced at three points:

• Signup — POST /api/auth/register in routes/auth.js. The client must supply a date of birth in YYYY-MM-DD form; the server computes calculateAge() in UTC and rejects the signup if the user is under MIN_AGE or the date is malformed. The exact same rejection message is returned in both cases so a probing client cannot distinguish "bad input" from "too young."
• Profile edits — PATCH /api/profile in routes/profile.js. If the caller updates their date of birth, the same calculateAge() check re-runs against MIN_AGE. The birth date is stored so the gate can re-verify if a user attempts to circumvent it.
• Post-moderation lockout — when an account is flagged (see User Reports & The Admin Action Panel), requireOnboarding in routes/auth.js rejects all calls into the feed, swipes, matches, and messages until the flag is cleared.

Age is computed via UTC so daylight-saving shifts never produce a one-day miscalculation. The same age gate is described in our Privacy Policy → Age Gate, so reviewers see one consistent message in both documents.

FUSE is not designed or marketed for children. We do not knowingly collect data from minors; if we learn that an account belongs to someone below MIN_AGE, we delete the account and its data.

5. Crisis Resources

People using a dating app can be in moments of acute distress. FUSE surfaces a set of free, confidential crisis resources inside the app so help is one tap away. The in-app list lives in public/app.html as CRISIS_RESOURCES and is rendered in the #safety view (showSafety()). The list is also reachable from the chat view (the chat-safety-row) and from the profile view.

The four resources currently surfaced to FUSE users are:

• 988 Suicide & Crisis Lifeline — free, confidential support 24/7. Call 988 · Web chat
• Crisis Text Line — text HOME to 741741 to connect with a volunteer crisis counselor. Text HOME to 741741 · Website
• RAINN (National Sexual Assault Hotline) — confidential support for survivors of sexual violence. Call 1-800-656-HOPE · Website
• Trevor Project (LGBTQ+ Youth) — crisis intervention and suicide prevention for LGBTQ+ young people. Call 1-866-488-7386 · Website

The same resource list links are wired into the chat UI and the profile UI so a user who feels unsafe can reach help without leaving the conversation that prompted it.

6. Response SLA

FUSE commits to the following response times for moderation and safety actions. These are operational targets, not arbitrary claims — they map to routes/admin-moderation.js and the moderation queue UI in public/app.html.

If a report involves imminent safety risk, it is escalated ahead of the SLA. We do not promise an instant response, but we do promise the report is read and actioned within the window above. To submit a report outside the app, or to flag a moderation concern to Trust & Safety directly, email us at:

hello@fuse-2.polsia.app