Before writing Flowvault, I spent an afternoon testing every “encrypted notepad” I could find and came away with the same feeling each time: the product was almost there, and then one specific compromise ruined it. This post is the catalogue of those compromises and the design decisions they pushed me toward.
The goal: a URL, a password, and a notebook
There is a very specific primitive I keep wanting and keep not finding: a URL I can open on anybrowser, type a password, and start writing. No account. No email. No app install. No sync client. No magic-link flow. No “just open the desktop app first.” A slug and a password is the entire identity system.
The reason is that I live across three laptops, a phone, a work machine I don't fully control, and the occasional hotel or library kiosk. The notepad I want exists in that lowest-common-denominator world. Anything with an account is already a worse fit than a URL I remember and a password I remember.
The service that historically gets closest to this primitive is ProtectedText. It's lasted for over a decade precisely because the shape is right. But the moment you read the source it serves, you find three things you wish weren't there. I'll get to those.
What's wrong with the 2026 landscape
Here's the honest tour. I respect every one of these projects — Flowvault wouldn't exist without their prior art — but each has at least one compromise I couldn't live with.
ProtectedText: three small things that compound
ProtectedText is the closest spiritual predecessor to Flowvault. Account-less, URL-shaped, been around since the early 2010s. Open their main.jsin the browser and you can watch the client code run. That's already better than most of the industry.
The three things that added up to “I'd like to write something new”:
- A legacy plaintext-password blob. Every save uploads two ciphertexts: a modern one and an
encryptedContentLegacyblob keyed directly by the raw password (for backwards compatibility with older clients). If the database is ever stolen, that legacy blob is crackable without any Argon2 work at all. A brand new design has no such back-compat cost, so I wanted to ship one. - Malleable cipher mode. The primary blob is AES-256-CBC via the legacy CryptoJS library. CBC is un-authenticated: bitflips in stored ciphertext go undetected and the plaintext silently mutates. AES-256-GCMhas been the default for authenticated encryption for about a decade; there's no reason a 2026 notepad should use anything else.
- Closed server code.ProtectedText's FAQ is explicit that the server side is closed source. The crypto runs client-side so that argument is partly valid, but you still can't verify what logging / rate-limiting / retention actually happens, and you can't self-host.
Standard Notes and Notesnook: beautiful, but accounts
Both Standard Notes and Notesnookare excellent end-to-end-encrypted note apps. Clients on every platform, real companies behind them, public audits, generous free tiers. If you want a long-term encrypted journal with full sync, they're both great answers.
They both require an account with an email. The moment you need an email, you need a lost-password flow; the moment you need a lost-password flow, someone's email provider is in your threat model. This is a fine trade if what you want is a persistent journal, but it rules out the anonymous-from-any- browser use case entirely.
Separate issue: most of the interesting features (Markdown, code editor, daily prompts, cloud backups, tags) sit behind a paid subscription. There's nothing wrong with charging for software, but it does push the basic “encrypted scratchpad I keep forever” primitive out of reach for a lot of people.
Privnote, CryptPad, Bitwarden Send: the wrong category
Privnote, CryptPad, Bitwarden Send, and 1Password Share are all great at what they do. They're just not the same primitive. Privnote and Bitwarden Send are one-shottools: you create a link, the recipient opens it once, and the note self-destructs. CryptPad is a collaborative office suite with encryption. None of them are “the notepad I return to for years.”
What I wanted was both. A persistent notepad for the long-lived stuff, and a one-shot burn-after-reading primitive for the ephemeral stuff, both at the same URL, both with consistent crypto, both open-source end-to-end. That became /send/new next to the main vault.
Obsidian and Joplin: brilliant, but not the use case
These are local-first desktop apps. If you have a real machine you control and want a knowledge graph with plugins, they're the answer. They don't help when you can't install software or when you want plausible deniability rather than local-disk encryption. The ideal setup is probably both — Obsidian at home, Flowvault everywhere else.
The feature nobody else had: plausible deniability
The specific gap that tipped me from “I should use X instead” to “I should write something new” was plausible deniability. VeraCrypt and TrueCrypt have had hidden volumes for disk encryption since forever. The idea translates perfectly to a notepad: one URL, one fixed-size ciphertext blob, multiple passwords, each unlocking a different notebook, and no way for the server (or anyone who stole the blob) to tell how many notebooks exist.
None of the incumbent notepads do this. ProtectedText is one-password-one-blob. Standard Notes gates sharing behind accounts. Privnote is single-shot. The obvious hole was “VeraCrypt for a browser notepad” and I spent a while convinced somebody must have shipped that already. They hadn't. So Flowvault became that, first.
The mechanism turned out to be straightforward once I stopped overthinking it — I wrote up the details in a dedicated deep-dive on hidden volumes. The short version: 64 fixed-size slots inside one blob, each password deterministically hashed to one slot, empty slots pre-filled with random bytes indistinguishable from real ciphertext.
The four design principles
Once I decided to write something new, the rules of the road crystallised quickly. Four principles, no negotiable ones.
1. Zero-knowledge is non-negotiable — and server code counts
The server stores opaque bytes. We don't learn your password, we don't learn your plaintext, we don't learn how many notebooks a vault contains. Fine — every modern notepad claims this. The interesting part is making that claim verifiable.
That means the entire stack ships in one repo: frontend, Cloud Functions (the trusted- handover sweep, the Encrypted Send read path, the time-lock writer), and the Firestore security rules — which are the actualboundary Google's infrastructure enforces between us and your data. If those three pieces aren't all in your hands, the zero-knowledge claim is on trust.
2. Modern crypto, honestly specified
Argon2id for key derivation, with 64 MiB of memory and 3 iterations (tuned to ~1 s on a mid-range laptop). AES-256-GCM for authenticated encryption. HKDF for key separation. No custom crypto, no rolled-my-own anything.
The security pagelists the exact parameters and the exact limits. No hand-waving: if something has a trade-off (and nearly everything does), it's written down next to the thing.
3. No account, ever, for anything the user does day-to-day
Opening a vault, adding a decoy password, sending a self-destructing secret, sealing a time-locked note, downloading a backup, restoring a backup on a self-hosted instance — none of these ever ask for an email or create a user record. The URL slug plus the password plus (for handovers) a trusted beneficiary's password is the whole identity system.
4. Features must compose, not fragment
The easy mistake is to ship the notepad, then launch a separate product for one-shot sharing, then another for time-locked messages, and another for encrypted sharing with a link. Three sign-ins, three brands, three threat models to keep straight. Flowvault puts all of it behind the same URL, the same crypto primitives, and the same open repo:
- The persistent notepad with hidden-volume deniability.
- A trusted handover that releases the vault to a beneficiary if you stop checking in.
- Time-locked notes keyed to the drand beacon so nobody — including us — can decrypt before the target date.
- Encrypted Send, the one-shot self-destructing cousin of Bitwarden Send and Privnote.
- Zero-knowledge
.fvaultbackups and plaintext Markdown export for migrations.
What Flowvault is not trying to be
It's worth being direct about the edges of the project, because they matter for deciding if Flowvault fits your workflow.
- Not a knowledge graph. No backlinks, no tags, no search index. Each slot holds around 8 KiB per tab in the default configuration. Spreading a notebook across slots is on the roadmap, but Flowvault is aimed at scratchpad + secret-store duty, not replacing Obsidian.
- Not a multi-device sync app. The notebook lives in one Firestore document. Two tabs on two devices with the same password work fine (with optimistic- concurrency conflict detection) but this is not a pass-through to a CRDT.
- Not an office suite. Plain text, one pane, Markdown-aware. If you want spreadsheets or slides with cryptography, use CryptPad.
- Not a funding story. We take direct crypto donations through NOWPayments(no donor email, no account, fresh address per donation). That's the whole business model. No ads, no analytics, no paid tier planned in the short term.
Where to start if you're curious
The rest of this blog is the feature-by-feature walkthrough:
- The beginner's guide walks through every click, end-to-end.
- Hidden volumes explained is the deep-dive on the deniability feature and why it's unique in this category.
- Trusted handover covers the inactivity-triggered release and the Bitwarden Emergency Access comparison.
- Time-locked notes walks through drand + tlock.
- Encrypted Send compared is the no-punches-pulled head-to-head.
- The
.fvaultbackup format documents the portability story.
Or just open the home page, pick a URL, set a password, and start writing. You can read every line of code that ran on your behalf afterwards.