OpenMic

A place to vent out your emotions without being judged.

OpenMic is an India-first, adult-only, pseudonymous community for sharing thoughts and replying with care. The interface is in English; the support chat also accepts Hinglish input and replies in English. A member's public username stays separate from their account identity.

It is not a diagnostic product, therapy service, crisis service, or an automatically monitored emergency-alert system.

Current status: this repository is a presentation demo. Posts, replies, chat history, account changes, and insights currently live in local browser state; no real participant content is stored, emailed, analysed, or sent to an AI provider. Do not use this build to collect real mental-health-related content until the release gates below are implemented and reviewed.

What is implemented

• Responsive React web experience for sign-in, Community, Insights, Chat, and Profile.
• A presentation-ready local account flow: email/password registration, Google sign-in onboarding, unique anonymous usernames, date-of-birth gating, and a clearly marked verification step.
• Theme controls and local demonstrations of account updates for password, email, mobile number, and username.
• Supabase-ready PostgreSQL schema, Row-Level Security policies, and trusted contact email function contracts.
• A consent-first Trusted Contact presentation flow plus server contracts. The real email feature is disabled by default and requires the documented pilot release gates before it can process a contact's data.
• Documentation and typed safety-model contracts that deliberately return not_configured until a separately approved model is available.

Before real participant data

The following work is intentionally still outstanding. It is a release plan, not a claim that these protections already exist in the demo.

1. Connect the product to the backend. Replace local demo state with Supabase Auth, the verified-email/18+ onboarding RPC, real profile updates, posts, replies, reactions, reports, and owner-only insights.
2. Build the private chat service. Store account-isolated conversations, serve them only through authenticated server endpoints, and add a reviewed bilingual English/Hindi/Hinglish support provider. The current chat is a scripted browser demonstration, not a live counsellor or model.
3. Enforce the 90-day lifecycle. Add the retention migration, query-time expiry filters, scheduled hard deletion, deletion/export flows, monitoring, and a backup/provider-retention agreement. The current SQL migration has no chat tables or 90-day content purge yet.
4. Build the private reflection pipeline. Use only opted-in, unexpired post/chat sources; keep outputs owner-only, non-diagnostic, versioned, and removable when consent is withdrawn. Do not create a public "depression score."
5. Finish safety and governance gates. Approve bilingual notices, privacy policy, terms, consent wording, operational ownership, moderation/review procedures, incident response, model card, dataset permissions, and a clinically informed validation plan.
6. Harden production operations. Add a staging environment, CI/CD protections, migration/RLS/deletion tests, safe observability, backups and restore drills, security headers, CAPTCHA and abuse controls before any broad public launch. Rate limiting remains deferred for this demo, but it must be introduced before opening unrestricted registration.

The detailed target is in the 90-day retention and isolation design.

Local development

npm install
npm run dev

Open the URL printed by Vite, normally http://localhost:5173.

Validate the frontend and Python safety contracts with:

npm run build
PYTHONPATH=services/ml python3 -m unittest discover -s services/ml/tests -v

Environment configuration

Copy .env.example to .env.local and configure values only when connecting the demo to Supabase:

cp .env.example .env.local

Never place service-role keys, SMS credentials, Resend keys, user posts, chats, or research data in the browser bundle, source control, test fixtures, or logs.

Recommended deployment

React / Vite frontend ──> Cloudflare Pages
                              │
                        Supabase Auth + Postgres + RLS
                              │
                   Edge Functions / private API / Cron
                              │
          future reviewed model and chat-provider interfaces

For a presentation-only demo, deploy the current static site to Cloudflare Pages. It does not need a database connection and must not receive real user content.

For a controlled live pilot, use separate staging and production Supabase projects, keep Supabase's service-role key and every provider credential on the server only, and deploy the Vite frontend to Cloudflare Pages from Git. Cloudflare Pages uses npm run build and publishes dist. Choose a region compatible with the approved India data-location decision (Supabase offers Mumbai / ap-south-1).

The free tier is suitable for development and disposable, non-sensitive test data. For real depression- or suicide-related content, use a paid, backed-up production database plan before inviting participants; a paused free project or unverified backup policy is not an acceptable 90-day retention promise.

Only these values are browser-safe:

VITE_SUPABASE_URL=
VITE_SUPABASE_ANON_KEY=

Never expose SUPABASE_SERVICE_ROLE_KEY, SMTP/SMS credentials, encryption keys, model-provider keys, trusted-contact secrets, or participant content in Cloudflare build variables, frontend code, Git, logs, or screenshots.

Official setup references: Cloudflare Pages for Vite, Supabase production checklist, and Supabase regions.

Data isolation and maximum 90-day retention

"Separate storage per user" should mean logical tenant isolation, not a separate database for each account. A per-user database is costly and hard to operate; one PostgreSQL project with account ownership keys, unexposed private schemas, narrow server APIs, and Row-Level Security is the stronger starting point.

auth.users → accounts
                 ├─ personas → community posts / replies (pseudonymous to peers)
                 └─ private account data → chat → analysis → private reflection

• Community posts and replies are intentionally visible to eligible community members, but never reveal account ID, email, mobile number, date of birth, chat history, or analysis result.
• Chat transcripts, model inputs/outputs, private reflection data, age data, and identity mappings belong only to their owning account. Browsers must not query raw chat or analysis tables directly; authenticated Edge Functions or narrow RPCs derive ownership from the session.
• Each raw post, reply, chat message, assessment, insight cache, report detail, and review record needs a server-set, immutable retention_expires_at no later than 90 days after creation. Clients cannot extend it.
• Queries stop returning expired content immediately; a protected scheduled purge physically deletes it before the deadline. A user delete, account delete, or analysis-consent withdrawal removes applicable data immediately, rather than waiting for the scheduled job.
• Backups and any AI provider are separate copies. We cannot truthfully promise "deleted everywhere within 90 days" until their retention/deletion terms are configured and tested. Do not send raw content to a provider that cannot meet the approved policy.

See the full storage, RLS, deletion, backup, and analysis design.

What we need from you before a live deployment

Do not send passwords, API keys, secret values, or participant data in chat. Enter secrets directly in the provider dashboards or grant the deployment team appropriate collaborator access.

1. Launch decision: presentation-only or real closed pilot; expected participant count, timeline, and monthly budget.
2. Ownership and domain: GitHub/Cloudflare/Supabase owners (plus a backup administrator with MFA), the staging and production domains, DNS access, and a monitored support email.
3. Authentication: confirmation of Google OAuth, the branded SMTP sender domain/provider for email verification and password reset, and whether mobile OTP is enabled now or deferred.
4. Privacy and retention: approved privacy notice, terms, community rules, 90-day scope for raw/derived content and backups, account-deletion/export process, and consent wording for safety scanning, private reflection, human review, and research.
5. Safety operations: named safety/moderation owner, support hours, escalation process, approved India crisis-resource copy, and confirmation that a trusted contact is user-selected and manually confirmed only. A model, post, or chat must never automatically notify a parent/guardian.
6. AI and data: approved provider, budget, data-processing/retention terms, no-training/no-retention posture where available, and bilingual clinical/privacy review for any dataset or model.

Deployment sequence

1. Deploy this build to Cloudflare Pages as a non-data-collecting demo.
2. Provision separate staging and production projects; configure domain, SMTP, Google OAuth, secrets, and Supabase migration testing in staging.
3. Implement and test real persistence, private chat/analysis APIs, 90-day retention, RLS isolation, export/deletion, and backup restore.
4. Obtain privacy, safety, model, and operational sign-off; run a small, consented closed pilot only after those gates pass.
5. Add rate limiting/CAPTCHA and abuse controls before expanding beyond that controlled cohort.

Important pilot boundaries

• Verified email is required before a member can complete onboarding or use community features. Google OAuth and email/password are both supported by the deployment design.
• Users complete a server-side 18+ date-of-birth gate and receive a unique public username through complete_account_onboarding.
• Mobile verification is optional authentication data and never public profile data; it never replaces verified email.
• A parent can be added only as a user-selected Trusted Contact.
• No model score, post, chat, diagnosis, location, or dashboard is included in a trusted-contact email.
• No model can automatically email a contact.
• Chat is a guided support experience until a privacy-safe, reviewed provider is approved.

See docs/README.md for the architecture, data governance, model roadmap, trusted-contact policy, authentication setup, retention and isolation design, and deployment guide.