Work / Bharat-First / MindGuard

No. 07 · Bharat-First · Mental Health
0

plaintext journal entries ever leave your phone

The stigma is the disease. Encryption is the cure.

Half of Indian college students live with anxiety or depression. Most never tell anyone · not because help doesn't exist, but because they don't trust where the words will end up. MindGuard is an end-to-end encrypted journal that runs sentiment analysis on the ciphertext itself. Crisis triage in under sixty seconds. Hotline alerted. Words never read.

0PII collected, ever
< 60sCrisis triage to hotline
CKKSHomomorphic scheme used
PREProxy re-encryption to hotline
100%Computation on ciphertext

Act I · The Problem

Mental health apps already exist. Trust is what doesn't.

According to the WHO, depression is the leading cause of disability globally and suicide is among the top twenty causes of death. The intervention exists. The barrier is the user's reasonable suspicion that what they type today might appear in a court order, an employer's background check, or a marketing dataset tomorrow.

Standard journaling apps store plaintext. Their privacy policies say "encrypted at rest", which only means the server holds the key. The moment they need to run a mood report, they decrypt your words. If the backend is compromised, subpoenaed, or sold, every sentence you wrote is in the open.

"Encrypted" apps that do analytics decrypt server-side the moment they need the data. That is not encryption. That is a delay.

And almost none of them route you to a real human when the words on the page indicate a real crisis. If they do, they reveal everything to do it.

Gap · 01
Plain-text storage masquerading as "encrypted at rest".
Gap · 02
Encrypted apps that decrypt server-side to compute anything.
Gap · 03
No automated crisis triage that respects the user's privacy.
Gap · 04
No auditable proof that the platform never read the user's words.
Gap · 05
No working pipeline from anonymous user to verified hotline without leaking the journal in between.

Act II · The Promise

Three guarantees. Cryptographic, not contractual.

Privacy promises are easy. Privacy proofs are not. MindGuard is built so that each guarantee is enforced by the math, not the team.

i.

The server cannot read.

Microsoft SEAL compiled to WebAssembly runs in the browser. Your journal is encrypted under your public key before it leaves the page. The Node API stores ciphertext blobs in PostgreSQL. The plaintext exists only in your browser's memory, ever.

ii.

The analytics run on ciphertext.

Django uses the FHE engine to homomorphically sum encrypted sentiment vectors over a sliding window, multiply by encrypted weights, and produce an encrypted risk score. No decryption. No "just for the report" exception.

iii.

The hotline is told only what it must know.

If the encrypted threshold check trips, a proxy re-encryption microservice transforms an "encrypted under user's key" alert into "encrypted under hotline's key" without ever decrypting. The hotline learns "anonymous user X in city Y is at risk." Nothing else.

Act III · The Product

From journal to triage. Without ever decrypting.

Five stages. Each one operates on ciphertext. Read the actor, read the action, read the artefact that moves to the next stage.

  1. Stage · 01

    Browser · key generation

    A homomorphic key pair is generated on signup. The private key never leaves localStorage. Only the public key is sent to the server, alongside a salted password hash.

    SentHE_PUB · sha256(salt || pwd)
  2. Stage · 02

    Browser · encrypted entry

    User writes a journal entry and ticks tags ("hopeless", "anxious"). The browser encrypts the text and the sentiment vector under the public key (CKKS batching) and uploads only ciphertext.

    UploadedCT_text · CT_vec[10]
  3. Stage · 03

    Django · homomorphic aggregation

    Django fetches the last seven days of encrypted vectors and sums them homomorphically, then computes a weighted dot product against a public weight set. The result is one encrypted risk score.

    ComputedCT_risk = Σ (CT_vec ⊗ weights)
  4. Stage · 04

    Django · encrypted threshold

    A homomorphic comparator runs CT_risk against a known threshold T, producing a single encrypted bit. Django still cannot tell whether it is zero or one. It only knows it has a comparison result.

    StoredCT_bit · audit_log_id
  5. Stage · 05

    PRE · re-encrypted alert

    The encrypted bit is sent through a proxy re-encryption microservice. The transformation key (set up at signup with the user's consent) re-keys the alert from "encrypted under user" to "encrypted under hotline" · without exposing plaintext.

    DispatchedEnc_hotline(at_risk · city)

Audit log discipline. Every operation · encrypt, aggregate, threshold, re-encrypt, dispatch · is logged with ciphertext-only inputs and outputs. The audit trail proves the platform behaved correctly without ever revealing what the user wrote. A "proof of non-disclosure" by construction.

Act IV · The Trust Model

Four parties. Each sees the minimum.

Party · 01

The user

Holds the private homomorphic key. Sees their own entries decrypted in their browser only.

Sees: everything theirs.

Party · 02

Node.js API

Stores ciphertext blobs in PostgreSQL. Routes signup, login and journal upload. Holds no decryption keys.

Sees: ciphertext only.

Party · 03

Django FHE engine

Aggregates encrypted vectors, computes encrypted risk and threshold bits. Cannot decrypt. Only operates.

Sees: ciphertext only.

Party · 04

Crisis hotline

Receives a re-encrypted "user X in city Y is at risk" alert. Decrypts only with their own private key.

Sees: anonymised crisis flag + city.

Act V · Proof

Why this is patentable.

In-browser FHE on commodity hardware

Microsoft SEAL CKKS compiled to WebAssembly runs on every modern browser, no specialised hardware. The platform is accessible to anyone with a phone, not only to people on workstations.

Homomorphic threshold comparison

Risk classification happens through an encrypted comparator circuit producing an encrypted boolean. The platform behaves correctly without learning whether the user crossed the line.

Proxy re-encryption for crisis alerts

Umbral-style PRE rewrites the encryption from user's key to hotline's key with no plaintext intermediate. The chain of custody from journal to triage never goes through the clear.

Encrypted audit trail

Every input, every transformation, every dispatch logged as ciphertext. The audit table is a "proof of non-disclosure" usable for compliance reviews and legal challenges alike.

Anonymous registration · zero PII

Username plus password. No email, no phone, no name, no demographics. The system cannot leak what it does not collect · by design and by audit.

Threshold under sixty seconds

Each new entry triggers a re-evaluation. A user crossing the encrypted threshold reaches the hotline's queue in under 60s, with the user's original consent, in their pre-chosen language.

The Stack

Three runtimes. One cryptographic boundary.

  • React.js
  • Bootstrap
  • Microsoft SEAL (WASM)
  • CKKS · BFV
  • Web Crypto API
  • Node.js · Express
  • PostgreSQL (BLOB)
  • Django · Python
  • PySEAL · PALISADE
  • Umbral PRE
  • TLS 1.3 · HTTPS-only
  • AES-256-GCM (text envelope)

If a teenager in crisis can trust this, your patients can too.

I build privacy-first products where the privacy is enforced by mathematics, not policy. Healthcare, mental health, finance, civic data. If you are working in a domain where the user has a real reason to fear disclosure, let's talk.