SelahKeep: Building a Private Space for Reflection Without Surrendering Your Words

Intimate writing deserves a product shaped around reflection, privacy, recovery, and trust, rather than another general-purpose workspace that happens to contain personal notes.

Some writing is meant to be shared. We prepare documents for colleagues, publish articles, organize project plans, and keep reference material that benefits from collaboration.

Other writing has a different character.

A prayer, an unresolved decision, a private reflection, or a note written during a difficult week may exist only because the writer believes the space is private. Treating that material as ordinary application data changes the relationship between the person and the product. If the operator can inspect it, process it, or silently introduce it into a new feature, the trust boundary is much wider than the interface suggests.

That is the problem I am exploring with SelahKeep.

Its positioning is intentionally narrow: “Pause and keep — an encrypted private vault for reflection, prayer, journaling, and remembrance.”

I am not trying to build another general-purpose knowledge workspace. I am building a place where contemplative writing, useful organization, memory, and privacy can coexist without requiring the service operator to read the content that makes the product valuable.

What SelahKeep Is, and What It Is Not

SelahKeep is designed for prayers, personal notes, decisions, daily writing, remembrance, and structured reflection. It combines a focused writing experience with local search, categories, tags, saved views, history, attachments, voice transcription, and optional boards.

Those capabilities could resemble a broad note-taking platform when listed individually. The difference is the boundary around the content.

Titles, Markdown bodies, categories, tags, and sensitive note states are encrypted in the browser before persistence. The APIs receive ciphertext and return ciphertext. There is no normal server or administrator path for decrypting private notes.

This does not make SelahKeep anonymous, eliminate every security risk, or turn encryption into a substitute for careful engineering. It establishes a specific product rule: intimate content should not need to become operator-readable data merely to support useful organization.

SelahKeep is currently an advanced MVP in development. I am describing the product and its architecture as they exist today, including the boundaries that still require work.

Account Access Is Not Vault Access

One of the most important design decisions is separating account authentication from vault decryption.

An account session answers a familiar question: is this person allowed to access this account? A user may authenticate with a password, OAuth provider, or passkey. That session can authorize API requests and synchronize encrypted records.

It does not decrypt the vault.

Opening the vault is a separate operation that requires access to the cryptographic material protecting the User Vault Key. Resetting the account password does not reveal that key, unlock existing notes, or recover a forgotten vault password.

This separation can initially feel less convenient than a system in which support can reset everything. It is also what prevents an account recovery mechanism from quietly becoming a universal content recovery mechanism.

The interface must make this distinction understandable. People should know whether they are signing into an account, unlocking private content, or configuring a recovery path. Hiding those differences behind a single login screen would make the system simpler to describe but harder to trust.

The Privacy Architecture in Plain English

Each vault has a randomly generated User Vault Key, or UVK. Each note receives its own Note Key. The note content is encrypted with its Note Key, while the Note Key is protected through the vault key structure.

The UVK can be unlocked through encrypted envelopes associated with a vault password, recovery phrase, or compatible passkey flow. New vault-password and recovery-phrase derivation paths use Argon2id for key derivation. Recovery phrases use a 12-word or 24-word BIP39 representation. Content encryption uses AES-GCM through browser cryptographic APIs.

This structure avoids using one human password directly as the key for every note. It also allows recovery and device-access mechanisms to evolve without re-encrypting all private content under a new password.

The server stores the encrypted records and the information required to synchronize them. It does not receive plaintext note titles, bodies, categories, tags, attachment contents, or sensitive workflow states through the normal application path.

That statement still needs an important qualification. A ciphertext-only server model is not the same as anonymity. The service can observe account information, technical identifiers, record counts, timestamps, ciphertext sizes, and operational request data. Those signals can reveal patterns even when they do not reveal the words themselves.

Privacy architecture should describe what remains visible as clearly as it describes what is hidden.

The Writing Experience Still Has to Be Good

A private product that is frustrating to use will eventually be abandoned or bypassed. Encryption cannot be the entire experience.

SelahKeep provides a visual Tiptap editor while keeping Markdown as the canonical content format. A writer can use the visual editor, switch to Markdown mode, use quick insert, enter focus mode, open a daily note, or begin with one of 14 templates.

Local drafts are encrypted so that an interrupted editing session does not require plaintext recovery data to be persisted casually in the browser.

After the vault is unlocked, full-text search runs locally across the title, body, category, and tags. The server does not need a plaintext search index. Searches can therefore reflect the actual private content while keeping that content inside the unlocked client session.

Each note can have one category and multiple tags. Smart filters, card and list views, and encrypted saved views provide organization without asking the backend to understand what the organization means.

The note lifecycle includes pinning, favorites, archive, trash, restore, permanent deletion, duplication, and resolved or unresolved states. Remembrance and weekly-reflection flows encourage returning to older writing rather than treating the vault as an accumulating pile of documents. Resolving a note can optionally prompt a final reflection.

These features are deliberately connected to reflection rather than generic document management. The goal is not to maximize the number of things a note can become. It is to help a person write, return, remember, and notice change over time.

History Without Erasing History

SelahKeep keeps immutable, encrypted note history.

A writer can navigate previous versions, compare changes through a diff, and restore an earlier version. Restoring does not rewrite the historical record as though later edits never happened. It creates a new current state while preserving the sequence that led there.

That distinction matters for reflective writing. A changed interpretation can be as meaningful as the final text. The product should allow someone to recover an earlier version without deleting the evidence of how their thinking evolved.

The server can persist and synchronize those encrypted versions without reading them. Comparison and restoration happen after the required material is available in the unlocked client.

Attachments, Voice, and Private Boards

Attachments are encrypted in the client under the relevant Note Key. The plaintext filename, MIME type, and bytes do not need to reach the server. Supported files can be previewed locally after decryption.

This creates more work than a conventional object upload. The client must validate, encrypt, transfer, decrypt, and preview files while handling failure carefully. That complexity is justified because attachment names and types can be sensitive even when the file contents are protected.

Voice follows the same local-first principle. SelahKeep supports dictation and audio upload using Whisper through transformers.js in a Web Worker, with WebGPU or WASM depending on the device. English, Portuguese, and Spanish are supported. Audio and transcription are not sent to a transcription service; only public model weights may need to be downloaded.

The product also includes encrypted Kanban boards. A board may be associated with a note or exist independently. Card titles and fields remain private, version history is maintained, and checklist items can synchronize locally with a board in both directions.

That synchronization does not require an LLM. Deterministic product behavior should remain deterministic when a model adds no real value.

Recovery, Passkeys, and Multiple Devices

Private encryption creates a difficult product tension: strong separation from the operator also limits what support can recover.

SelahKeep addresses this through explicit vault recovery mechanisms rather than a hidden administrative escape path. A user can prepare password, recovery-phrase, and passkey-based envelopes for the UVK.

Vault passkeys use the WebAuthn PRF extension. A passkey signature is never treated as an encryption key. Signatures authenticate; the PRF produces local key material designed for this purpose.

SelahKeep currently uses @tgoliveira/vault-core 1.3, which supports synchronized passkey credentials through a bounded set of envelope variants and browser-specific bindings. The PRF result remains local. Supporting synchronization does not mean placing a universal decryption secret on the server.

Multiple-device access still requires deliberate enrollment and recovery planning. A synchronized account login alone cannot decrypt the vault. The device needs a valid way to unlock the UVK.

The default auto-lock interval is 15 minutes, with a manual lock available at any time. The decrypted UVK remains in memory only for the unlocked session. The product also provides a security review, a local recovery drill, and safe operational events that avoid recording private content.

Account deletion removes active account data and associated keys from the active system. It should not be described as an instant erasure of every backup copy. Backup retention remains subject to the documented policy and infrastructure provider behavior.

Selective AI Requires an Explicit Trust Boundary

By default, SelahKeep does not send private content to an AI service, perform server-side AI processing on notes, or use private writing to train a model.

MCP and other agent integrations are opt-in and granular. A user selects the notes or boards an agent may access. The server can remain ciphertext-only, but once the unlocked client allows an agent to read selected content, the AI provider becomes part of the trust boundary for that interaction.

That boundary should be visible at the moment of consent. “AI enabled” is too broad to be meaningful. A person needs to understand which item is being shared, with which integration, for what action, and under whose data policies.

Encryption protects data along a defined path. It cannot make a third party unable to read content that the user has explicitly authorized that party to receive.

A Brief Note on the Stack

SelahKeep is built with Next.js, React, TypeScript, PostgreSQL, and Drizzle. Account authentication uses @tgoliveira/secure-auth. Cryptographic profiles, primitives, and passkey helpers come from @tgoliveira/vault-core. The browser uses Web Crypto AES-GCM, Argon2id, and WebAuthn PRF. Local voice uses Whisper, while selected agent integrations use MCP.

The stack is less important than the boundaries between its parts. Authentication, encryption, storage, local processing, and optional external integrations need separate responsibilities that remain understandable under failure.

Honest Limitations and Current Maturity

SelahKeep does not yet provide bulk import and export. Community sharing and advanced collaboration are also unavailable. These are meaningful gaps for people moving from an established knowledge platform or working in shared spaces.

The web delivery model has residual risk. A compromised JavaScript bundle, successful XSS attack, malicious dependency, or compromised delivery path could access keys while the vault is unlocked. CSP, HSTS, dependency controls, sanitization, and short-lived in-memory key handling reduce that risk, but they do not eliminate it.

The project also has operational gates before a real beta: completed privacy and legal policies, data-residency decisions, incident-response procedures, verified backups, and an external security review. SelahKeep should not be represented as externally audited or ready for broad adoption while those gates remain open.

The ciphertext-only design protects note content from normal server-side inspection. It does not remove metadata, endpoint abuse, account compromise, device compromise, browser risk, recovery mistakes, or infrastructure failure from the threat model.

Being precise about those limits is part of the product. Privacy claims should remain narrow enough to be tested and understood.

Principles I Am Taking Forward

First, intimate content deserves its own threat model. It should not inherit the assumptions of a generic productivity database.

Second, account authentication and content decryption are different responsibilities. Combining them may simplify support, but it quietly expands who can recover private material.

Third, privacy must include the useful features around writing. Search, history, drafts, attachments, voice, and boards all need designs consistent with the core boundary.

Fourth, recovery is part of the product experience. It requires clear language, drills, multiple paths, and honest consequences.

Fifth, AI consent must identify the content and provider entering the trust boundary. A global toggle is not sufficient.

Finally, calm design and precise language are security features. SelahKeep’s “Stillness” direction uses warm neutrals, lilac and purple, Schibsted Grotesk, mobile-first layouts, light and dark themes, and human wording. The interface should help people pause without using cryptographic jargon or exaggerated security promises.

A Place Worth Trusting

SelahKeep is an attempt to make private writing useful without first making it legible to the service operator.

That requires more than encrypting a text field. It means separating account and vault access, designing recovery honestly, keeping search and voice local, protecting attachments and history, and treating every optional integration as a new trust decision.

The project is still evolving, and important operational and security gates remain. I will continue documenting the architecture, product decisions, limitations, and repository as that work progresses.

You can follow the project and its technical decisions on GitHub.