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
Instagram, Facebook, Telegram, Google, or other URLs are labelled “unverified.”
OAuth verification is not implemented in the current MVP.

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.

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.