Privacy-First Personal Journal

Why we are building this

A journal is the most sensitive dataset a person voluntarily creates: doubts, health worries, relationship friction, half-formed ambitions. Most journaling apps with AI features resolve the resulting tension in the wrong direction — entries go to a server, the model reads them there, and the privacy policy does the reassuring. We think the right resolution is architectural: the interesting AI runs where the journal lives, on the device, and the server’s role shrinks to moving ciphertext between a person’s own phones. This is an internal HummingByte product in development. What follows are our design intents and the questions we are still building through — not launch claims.

Design intents

1. The model comes to the data. Reflection prompts, recurring-theme detection, and periodic pattern summaries are computed by on-device models. No entry text, embedding, or derived signal leaves the device unencrypted — the feature set is bounded by what the phone can compute, and we accept that trade.
2. End-to-end-encrypted sync. Keys are generated and held on the user’s devices; our servers store and relay ciphertext. We cannot read journals, which also means we cannot recover one for a user who loses every device and their recovery key. That sentence stays true even though it will cost us support tickets.
3. The journal is the product, not the input. No ads, no data monetization, no secondary use — a paid app, priced plainly. A business model that survives only by reading the data would eventually read the data; ours can’t, so it won’t.
4. Writing first, features second. The core loop is a calm editor that opens fast and gets out of the way. Every AI feature is judged against the risk of making the journal feel observed — the one feeling that kills journaling.

What the AI does — and what it never does

On-device models earn their place in three narrow jobs. Prompting: a gentle opening question in the evening, drawn from recent themes rather than a generic deck — skippable, and it learns from being skipped. Reflection: on request, a short summary of the week’s recurring threads, phrased as observations (“late-night entries mention sleep often”) with links to the entries behind each observation, never conclusions about the person. Retrieval: natural-language search over one’s own past (“when did I last feel like this about work?”) — arguably the feature that makes years of journaling compound.

Hard boundaries, written before any model was chosen: no mood scoring presented as assessment, no advice, no diagnosis, nothing that positions the app as a therapist. If entries suggest acute distress, the app does exactly one thing — surface local crisis resources, plainly and without commentary — and never gates, analyzes, or reports. It is a notebook with a good memory, not a clinician.

The daily loop we are designing for

1. Open editor first — cold start budget under one second
2. Optional prompt drawn from recent themes, on-device
3. Write text or dictation, transcribed locally
4. Encrypt & sync ciphertext to relay, keys stay on device
5. Weekly reflection requested, not pushed — user opens it

The amber step encodes a position we keep returning to: summaries are pulled, not pushed. A journal that messages you about your own patterns has quietly become surveillance with good intentions.

The privacy architecture, concretely

• Entries live in an encrypted on-device store; the encryption keys never leave the user’s device set
• Sync is client-side encrypted per entry; the relay sees account identifiers, ciphertext blobs, and timestamps — enough to sync, not enough to know
• Device enrollment uses key exchange between the user’s own devices; a recovery phrase is the sole fallback, stated bluntly during onboarding
• On-device inference runs against the local store only; models ship with the app and update through app releases, so there is no per-request cloud dependency to leak into
• Diagnostics are opt-in and content-free — crash traces and performance counters, never text, never derived-from-text signals

The uncomfortable honesty: this architecture means we cannot run the easy playbook — no server-side model upgrades applied to everyone’s history overnight, no “we noticed users like…” analytics, no support-agent restoring a lost journal. Each of those is a feature other apps have because they can read the data. We are building the version of the product that works without that power.

The business model, stated plainly

Paid up front or a simple subscription — pricing is an open question below — with no free tier subsidized by data and no ad inventory. We think of the business model as part of the security model: incentives are the only privacy guarantee that holds over a decade, through pivots and acquisitions. An app that cannot read your journal and has no economic reason to want to is a different product from one that merely promises not to.

Open build questions

We would rather publish these than pretend they are settled:

• On-device quality floor. Current phone-class models handle prompting and retrieval well in our testing so far; multi-month pattern summaries strain them. If quality on older devices falls below usefulness, do we cut the feature by device tier or hold it entirely until models catch up? Leaning: hold — a two-tier journal feels wrong.
• Recovery honesty. How aggressively should onboarding force the recovery phrase before real data exists in the app? Every design that softens the moment increases the number of people who will someday lose everything, and “someday” is our fault either way.
• Dictation boundary. On-device transcription quality varies sharply by language; shipping cloud transcription would break the architecture’s one-sentence promise. The current answer is on-device only, with honest language support, and it may stay that way.
• Reflection cadence. Weekly feels right in internal use; monthly may read as more truthful for slow-moving themes. Needs longer self-testing than we have given it.
• Pricing shape. One-time purchase matches the “you bought a notebook” mental model; sync infrastructure has recurring cost. Unresolved, and we won’t resolve it by adding ads.

Where the build stands

The editor, the encrypted store, and single-device journaling exist and are in daily use inside the studio. Encrypted multi-device sync and the reflection engine are in active development, in that order — sync first, because trust in the substrate precedes any feature built on it. No launch timeline is promised here, and no numbers exist worth citing; the product ships when the recovery flow, the sync layer, and the boundaries above survive our own use without exceptions.

How we will judge it before anyone else sees it

• Habit test on ourselves: does entry frequency hold after the novelty fades, with prompts off as the control
• Cold-start budget: under one second to a writable editor on our oldest test devices
• Sync chaos drills: conflicting offline edits on three devices must converge without silent loss
• Recovery rehearsal: a full device-loss-and-restore walkthrough that a non-technical person completes unaided
• The observed-feeling check: after a month, does writing in it still feel private — the one metric we can only measure on ourselves, honestly