who_need_help/docs/trust-safety.md

Trust, safety, and abuse model

Status: MVP policy and implementation requirements. This document does not claim that the system can eliminate bad actors.

Safety boundary

Who Need Help is a coordination tool for adults. It is not an emergency service. Every urgent screen must tell users to contact local emergency services when life, health, fire, violence, or immediate danger is involved.

The medicine category is limited to pickup/delivery of an already purchased or reserved legal item. Requests for medical advice, prescriptions, cash advances, controlled substances, or suspicious repackaging are reportable and removable.

Social activities are a separate product mode. They do not use handover codes, helper reviews, live movement evidence, or the helper leaderboard. The organizer approves participants individually. Public viewers see only an approximate or hidden meeting location; exact coordinates and group chat are available only to approved participants. Users are told to use a suitable public first meeting point and to keep home addresses, access codes, travel documents, and other sensitive details out of public text.

Verified completion

A completion is counted as verified only when all of these occur:

1. A helper accepted the request.
2. Both parties confirmed the completion.
3. The requester shared the one-time handover code with the helper.

Optional location proximity is supporting evidence, never a mandatory prerequisite. This avoids excluding users who deny geolocation permission, while making simple remote rating rings less useful.

The public reputation summary separates:

• completed requests;
• unique people helped;
• verified handovers.
• optional location-supported interactions.

The helper leaderboard ranks unique counterparts with optional proximity plus helper-movement evidence first, then unique handover-verified counterparts, then unique counterparts, and only then raw completions. Repeated work with the same person cannot increase the primary unique counters.

Reviews

Reviews are double-blind. A review becomes visible only after both participants submit. There is no automatic reveal timeout in the MVP. Reviews are allowed only for completed matched requests.

Identity and social links

Email ownership can be confirmed through a magic link. Manually attached GitHub, Instagram, Facebook, Telegram, Google, or other URLs are labelled “unverified.” If the operator configures a GitHub OAuth App, a user can instead complete a state- and PKCE-protected authorization flow and receive a verified GitHub badge. The flow is bound to the initiating signed-in user, each GitHub account can belong to at most one local account, and the provider access token is discarded after the public profile is read.

No other social provider is currently verified. A verified GitHub profile is one trust signal, not government identity verification or proof of real-world safety.

The MVP uses 18+ self-attestation. It does not imply government identity verification.

Implemented abuse controls

• Completion requires both confirmations plus a request-specific handover code.
• Public reputation separates completed work, unique people, and handover-code verification.
• Reviews require a completed assignment and remain hidden until both parties submit.
• Blocks remove discovery in both directions, prevent acceptance/new chat, and delete the pair's active exact positions.
• Reports target exactly one request, assignment, or message. A moderator can load chat only through an assignment/message report.
• Missing optional proximity/movement, repeated pairs, reciprocal direction, and configured action velocity create review signals. They do not automatically punish an account.
• PostgreSQL action buckets enforce only operator-supplied policies across all replicas. Registration and magic-link email scopes can also be configured.
• No public exact location by default.

No numeric rate policy is enabled by default because no threshold has been approved or measured for this deployment. Supported action names currently include registration_email, magic_link_email, create_request, accept_request, start, confirm, verify_handover, cancel_request, withdraw_assignment, send_message, start_tracking, tracking_position, review, report, block, category_proposal, and category_vote. Activity actions additionally include create_activity, join_activity, and send_activity_message.

The system does not claim to be bot-proof. Email confirmation, database uniqueness, unique-counterpart ranking, location evidence, velocity policies, signals, and human review raise the cost of simple rating farms but cannot prove identity or eliminate coordinated abuse.

Moderator access

A moderator can access private chat only from a specific assignment or message report. Every access records the moderator, report, linked assignment, message count, and timestamp. The report itself contains the reason. Browsing private conversations without a qualifying report is not a product capability.

The same boundary applies to Activity group chat. Reporting an Activity itself does not reveal its private chat. Only a report targeting a specific Activity message permits the moderator to load that Activity's group conversation, and the evidence access audit records the Activity and message count.

Report, request, signal, category, role, and account moderation are role protected. The local Codex batch receives proposal text and aggregate vote counts only. It receives no private messages, email addresses, OAuth tokens, exact coordinates, or raw tracking routes.

Money

Help is free. A helper may add an external voluntary tip link. It appears after completion, is labelled optional, and routes directly to the helper. The platform does not calculate, collect, split, refund, guarantee, or report the payment. The legal and tax treatment remains dependent on the users' jurisdiction and is not represented by the product.

Operational response

Reports have open, reviewing, resolved, and dismissed states. A severe report can hide a request and temporarily restrict an account pending review. Suspension invalidates that account's login sessions. The first administrator requires an explicit one-time operational bootstrap, and later role changes are audited; the last administrator cannot demote themselves. The operator must publish jurisdiction-specific emergency contacts, privacy notice, prohibited-items policy, and data-retention policy before public launch.

Public support and legal removal are separate from in-product reports. Support, moderation appeals, privacy/data requests, general electronic removal notices, and a dedicated TAKE IT DOWN intake are described in docs/support-and-content-removal.md. Public contacts are verified through an emailed private status link; moderator/admin decisions and access remain audited. The removal forms never accept intimate-media uploads.