Built by Flowdesk — ex‑FlowCrypt (iOS + Chrome Ext.). Privacy apps, E2EE systems, native & mobile.See workcontact@flowdesk.tech
Flowvault

Flowvault FAQ

Questions we get (or expect to get) about our zero-knowledge encrypted notepad, the Markdown preview with security-first defaults (blocked HTML, click-to-load external images, no-referrer external links, locally-highlighted code blocks), Bring-Your-Own-Storage local vaults stored as a single .flowvault file on your device, the trusted handover to a beneficiary, drand-backed time-locked notes, Encrypted Send, .fvaultencrypted backups and restore, and how Flowvault compares to ProtectedText, Standard Notes, CryptPad, and other alternatives. If yours isn't here, open an issue on GitHub.

About Flowvault

What is Flowvault?+
Flowvault is an encrypted notepad. You pick a URL like useflowvault.com/s/my-notes, set a password, and write. Your notes are encrypted in your browser before they reach our server, so we only ever see an opaque ciphertext blob.
Do I need to create an account?+
No. There is no sign-up, no email, no phone number. A URL slug plus a password is the entire identity system.
How much does it cost?+
Free for normal personal use. We may add a paid tier later for custom domains and larger vaults, but the core notepad will stay free.

Comparisons: Flowvault vs ProtectedText, Standard Notes, CryptPad, Privnote, and other encrypted notepads

I already use ProtectedText. Why switch?+
Four concrete differences, in honest order:
  1. No legacy plaintext-password blob. Inspect protectedtext.com/js/main.js— every save still uploads a parallel encryptedContentLegacy blob keyed only by the raw password (for backwards compatibility with older clients). If their database is ever stolen, attackers can crack that legacy blob without doing any Argon2 work at all. Flowvault has no such fallback — every blob requires the full Argon2 chain.
  2. Authenticated encryption. Flowvault uses AES-256-GCM, which detects any tampering with the ciphertext. ProtectedText uses AES-256-CBC via the legacy CryptoJS library, which is malleable: bitflips in the blob go undetected.
  3. Plausible deniability via hidden volumes.One Flowvault URL can hold multiple independent notebooks, each behind a different password, all packed into one fixed-size blob. ProtectedText is one password, one blob — no decoy possible without a breaking format change.
  4. Open backend.ProtectedText publishes its client JS for inspection but their FAQ explicitly says the server code is closed. Flowvault publishes the frontend, the Cloud Functions, and the Firestore security rules — the entire stack is reviewable, licensed, and self-hostable.

What we're NOT claiming:ProtectedText today actually does use Argon2id (32 MiB, adaptive ~300 ms) for the primary blob — it's a real KDF, in the same family as ours (64 MiB, 3 iters, HKDF expansion). The KDF gap is small. The legacy-blob issue, the malleable cipher, and the lack of deniability are the real differences.

What is "plausible deniability" in practice?+
One URL can hold multiple notebooks, each behind a different password. The server stores one fixed-size blob; it cannot tell how many notebooks live inside. If someone coerces a password out of you at a border crossing or in a legal process, you hand over a decoy password that opens a decoy notebook full of mundane content. Your real notebook stays as cryptographically random-looking bytes in the same blob. Nobody — not us, not an attacker with a copy of the blob — can prove another notebook exists.
Is ProtectedText insecure?+
No. ProtectedText is a solid, long-running, popular service and we respect what they built — we wouldn't exist without it as prior art. Flowvault is aimed at people who want a stronger threat model (coercion, offline brute force of stolen DBs, tampering, open server code) and don't mind switching. For a quick private scratchpad, ProtectedText is perfectly fine.
How does Flowvault compare to Standard Notes?+
Standard Notes is an excellent end-to-end-encrypted note-taking app focused on long-form personal knowledge management. It has clients on every platform, sync across devices, and a real company behind it. It also requires an account (email + password), and most useful features (Markdown rendering, code editor, daily writing prompts, cloud backups, tags) live behind a paid subscription.

Flowvault has a different shape: no account, no email, no app install, no subscription. You type a URL, set a password, and start writing in a browser tab. It's closer to ProtectedText than to Standard Notes in spirit. We add hidden volumes and a fully open backend on top. Pick Standard Notes if you want a long-term encrypted journal across devices; pick Flowvault if you want a no-account scratchpad with deniability.

How does Flowvault compare to CryptPad?+
CryptPadis a fantastic, fully open-source encrypted office suite (docs, sheets, slides, kanban, code) built by XWiki SAS in France. It's the right answer if you need real-time collaborative editing with cryptography. The trade-off: long-term storage requires an account, the UI is a full app rather than a notepad, and it doesn't offer hidden-volume deniability — one user, one set of pads.

Flowvault is much smaller in scope (plain text, single pane, one URL = one vault). If you want a Google Docs replacement, use CryptPad. If you want a hidden, deniable scratchpad you can open from any browser without signing in, use Flowvault.

How does Flowvault compare to Privnote, OneTimeSecret, PrivateBin, and other burn-after-reading services?+
Flowvault now does both — long-lived notebooks andone-shot self-destructing links — so you don't have to pick a second tool.
  • For the persistent side (the notepad you return to for years), Flowvault uniquely offers plausible-deniability hidden volumes: multiple passwords on the same URL unlock different notebooks. Privnote, OneTimeSecret, PrivateBin, and Yopass don't do persistence at all.
  • For the one-shot side (a password for a colleague, a recovery phrase, an API key), Encrypted Send is Flowvault's direct answer. AES-256-GCM in the browser, key in the URL fragment, server-enforced view cap (default 1) with atomic hard-delete, optional Argon2id password gate on top, expiry up to 30 days, and the whole stack is open source end-to-end (frontend + Cloud Functions + Firestore rules). See the full comparison table on the homepage.

The short version: use Privnote/OneTimeSecret if you're already there, use /send/new if you want an account-less, open-source alternative that lives next to your long-lived vault.

How does Flowvault compare to Joplin and Obsidian?+
Joplin and Obsidian are local-first desktop note apps. Joplin offers optional E2EE sync through your own provider; Obsidian sells Obsidian Sync as a paid E2EE add-on, otherwise notes live on your disk. Both are excellent for power users who want a knowledge graph, tags, plugins, and offline-first storage on a real device.

They're a different category from Flowvault. Flowvault is designed for the case where you can't install software (a friend's laptop, a school computer, a hotel kiosk, a phone you don't own), or where you want plausible deniability rather than local-disk encryption. The ideal setup is probably both: Obsidian or Joplin at home, Flowvault for everywhere else.

How does Flowvault compare to Notesnook?+
Notesnookis a polished, fully open-source end-to-end-encrypted notes app with native clients on every platform, a free tier, and a paid Pro tier for advanced features. It's a strong choice if you want an Evernote-style app with real cryptography. Like Standard Notes, it requires an account and is centered on a multi-device app experience.

Flowvault is account-less and browser-only. We don't compete on app polish or device sync — we compete on zero metadata(we don't even know who you are) and hidden-volume deniability. If you want an encrypted note app, Notesnook is great. If you want an encrypted note URLwith deniability, that's us.

I used Skiff Notes. Where should I go now?+
Skiff was acquired by Notion in early 2024 and shut down. If you liked Skiff for the encrypted-Notion vibe, look at Proton Docs or CryptPad for document-style use, or Standard Notes / Notesnookfor note-app use. For quick anonymous scratch notes, Flowvault and ProtectedText are the spiritual successors to the “just give me a URL” model.
How does Flowvault compare to Bitwarden Send / Bitwarden Notes / 1Password Secure Notes / 1Password Share?+
Password managers' secure-notes features are excellent for short, structured secrets attached to a credential (license keys, recovery codes, one-line answers). They live inside an account protected by a master password and your device's vault. Two separate comparisons here:
  • Bitwarden Send / 1Password Share (ephemeral one-off shares). Flowvault now ships Encrypted Send, which plays in this exact lane — and unlike Bitwarden Send / 1Password Share, it doesn't require an account on the sender'sside and the entire stack (frontend, Cloud Functions, Firestore rules) is open source in a single repo. Password gate, URL-fragment key, atomic server-enforced view cap — same threat-model promises.
  • Bitwarden Notes / 1Password Secure Notes (persistent notes inside a password manager). Flowvault is for free-form text you want to keep coming back to, without an account, without installing anything, and with the option to hide some of it behind a decoy password. Use both: structured credentials in your password manager, free-form scratch + deniable notebooks in Flowvault.
How does Flowvault compare to Cryptee, Turtl, HedgeDoc, dontpad, Etherpad?+
Quick survey:
  • Cryptee: Estonia-based, encrypted notes and photos, account required. Beautiful but a different shape than a no-login notepad.
  • Turtl: open-source encrypted notes app with account-based sync. Closer to Standard Notes than to ProtectedText.
  • HedgeDoc (formerly CodiMD, fork of HackMD): collaborative Markdown editor. Excellent for shared drafts but generally not encrypted at rest unless you self-host with care.
  • dontpad, Etherpad, pad.riseup.net: collaborative pads, notencrypted — the operator can read your content. Useful for non-sensitive coordination, not for secrets.

If your top requirement is “an encrypted notepad I can open in a browser without signing in,” the realistic field is essentially Flowvault and ProtectedText. Everything else is a different category.

Security

What does the server actually see?+
A SHA-256-derived site id (not your slug), an opaque ciphertext blob, your Argon2id salt, the KDF and volume parameters, and timestamps. That's it. No passwords, no keys, no plaintext, no clue how many notebooks a vault contains.
Is my password ever transmitted?+
No. Your password is used purely in-browser to derive the encryption key. The only thing your browser sends to the server is ciphertext. Verify this yourself by opening the Network tab while saving.
Why Argon2id instead of PBKDF2 or SHA-512?+
Because modern password cracking is done on GPUs and ASICs that are terrible at the “memory-hard” access patterns Argon2id forces. Iterated SHA-512 or PBKDF2 cost attackers cents per billion guesses on commodity GPUs. Argon2id with 64 MiB of memory forces each guess to allocate real RAM, slashing throughput by orders of magnitude. It's also the winner of the Password Hashing Competition and the OWASP-recommended default.
What if you get hacked?+
An attacker who steals the entire Firestore would get a pile of ciphertext blobs plus salts. No passwords, no keys. They would still have to run Argon2id-protected offline brute force, one password at a time, per vault. That's the zero-knowledge design working as intended.
Can you be compelled to hand over my notes?+
We can only hand over what we have: ciphertext. We don't have your password, your derived keys, or any way to recover them. If a court ordered us to give a notebook to a third party, we would give them the same ciphertext you could download yourself from Firestore — unreadable without your password.
Is the frontend code verifiable?+
The source is open. Today you trust that the JavaScript your browser downloads matches the source on GitHub — the same trust assumption as every browser-based crypto app. We plan to publish signed bundle hashes for each release so you can verify the bundle your browser ran. See the security page for the current state.

Trusted handover & time-locked notes

What is the trusted handover?+
An opt-in way to say: “if I stop checking in for X days, let this trusted person decrypt my vault.” You pick a beneficiary password (different from your own) and share it with them out of band. The browser derives a beneficiary key with Argon2id, wraps your master key with AES-GCM under it, and uploads a ~60-byte wrapped blob. Every save counts as a heartbeat; if you go quiet past the interval + grace you configured, an hourly Cloud Function marks the vault released, and the beneficiary can then visit the URL, enter their password, unwrap the master key, and read the notebook.
Is the trusted handover zero-knowledge too?+
The cryptography is, yes — the server never sees the beneficiary password, the master key, or the plaintext. We do acknowledgetwo visible side-effects we can't avoid without losing the ability to schedule the release: the existence of a handover on the vault, and the interval / grace / last-heartbeat metadata. The wrapped key and beneficiary salt themselves are opaque ciphertext.
Can someone else fake a heartbeat to keep my vault alive forever?+
Only if they already have your master key. Heartbeats piggyback on saves, and every save re-encrypts the whole ciphertext blob with the master key — so an attacker with only read access to the document cannot produce a valid new ciphertext to extend the timer. They can overwrite it with garbage (that's a general issue with any password-only zero-knowledge notepad, and the defense we plan to add is a Cloud Function that requires a proof of master-key knowledge for writes). But they can't secretly keep the handover from firing.
Can I cancel a trusted handover?+
While it's still active (not released yet): yes, any time, from the editor toolbar — that removes the wrapped key blob from the document entirely. Once it has released, no: the Firestore rules lock the document against further writes, because the wrapped key has already been sitting in a potentially-public document and anyone who knew the URL could have grabbed a copy. After a release you should treat the URL as burned and start a new vault.
What happens to my other hidden notebooks when the handover fires?+
Only the notebook that belongs to the master key you wrapped is exposed to the beneficiary — by design. The other slots in the vault (decoys, or notebooks under other passwords) stay as random-looking bytes that the beneficiary has no key for. If you care about this, configure the handover from a decoy notebook's session rather than from your primary one.
Do Standard Notes / ProtectedText / Privnote have a trusted handover?+
Not out of the box. Standard Notes has paid cloud sharing but not a time-triggered release mechanism. ProtectedText, Privnote, CryptPad, and most “zero-knowledge notepad” services have no concept of inheritance — forget or lose the password and the data is gone. Bitwarden's Emergency Access feature is the closest mainstream analog, but it requires accounts on both sides and is gated behind a paid plan. Flowvault ships the trusted handover as a first-class, client-side, account-less feature.
Time-locked notes — are those the same as the trusted handover?+
No, they're complementary. The trusted handover uses a password-wrapped key that a server unveils after a timeout. Time-locked notes use the drandpublic randomness beacon's threshold BLS signatures as the unlock material — nobody, not us, not you, can decrypt before drand publishes the round signature. Different threat models, different mechanisms.
How do time-locked notes work?+

You compose a message and pick an unlock moment. Your browser:

  1. computes the drand round number whose signature will be published closest to your unlock moment (30-second granularity);
  2. encrypts your plaintext to that round using tlock— identity-based encryption over BLS12-381, with the round number as the identity;
  3. uploads only the opaque ciphertext, the target round, and the drand chain hash to a write-once timelocks Firestore collection.

We hand you back a share link like useflowvault.com/t/xyz. Visit it any time: before the unlock moment you see a countdown, after it your browser grabs the drand round signature and decrypts locally. Flowvault cannot unlock it early — the key literally doesn't exist yet.

Who / what is drand?+
drandis a distributed randomness beacon operated by a network of independent organisations (Cloudflare, Protocol Labs, the EPFL DEDIS lab, Kudelski Security, and others). Every 30 seconds the network publishes a fresh BLS threshold signature. Nobody can produce that signature in advance because nobody holds the full private key — a supermajority of node operators have to collaborate for each round. That's what makes it safe to use drand rounds as identities for time-lock encryption: the “unlock key” for a round doesn't exist until enough honest operators sign.
Can Flowvault or law enforcement decrypt a time-locked note early?+
No. This is the central point of using drand + tlock rather than a server-held key. Until the target round's signature is published, the decryption key does not exist in any one place — not on our servers, not in your browser, not in a hardware module somewhere. A subpoena against Flowvault would yield only ciphertext and a target round number. A subpoena against drand would fail too: it would have to compel a supermajority of independent operators across jurisdictions to collude.
What are the limits and leaks of time-locked notes?+
The target round, and therefore the approximate unlock wall-clock time, is visible to the server — readers need it to know when to retry. The share URL is the access credential: anyone with the link can open the note once the round releases, so treat it like the secret (or see the next FAQ for an optional password gate). Message size is capped at 128 KiB of plaintext. We rely on drand mainnet staying honest and on BLS12-381; if drand ever deprecates the scheme we'll migrate.
Can I require a password in addition to the time-lock?+
Yes. When composing a time-locked note, tick “Also require a password to read”. The note is then wrapped in two layers: an inner AES-256-GCM layer keyed by Argon2id(password), and an outer tlock layer keyed to the unlock round. The reader has to wait for the round to release andenter the password. Neither gate is redundant: before the round the capsule is completely opaque (even to someone who knows the password); after the round, the bytes become a password-shaped blob that still needs the key. We store no password and no hint, so if the reader forgets it, the message is gone even after the time-lock opens. Share the link and the password through different channels — e.g. link over email, password by phone call or Signal.
How is a time-locked note different from Privnote or other burn-after-reading links?+
Privnote-style services encrypt a note, put the key in a URL fragment, and delete the ciphertext the first time someone opens it. Anyone who gets the link right now can read it. Flowvault time-locked notes are the opposite: the link can be public, but nobody— not even the sender — can read the contents before the unlock moment. Great for a future-self letter, a scheduled disclosure, a capsule for an anniversary, or a trust-minimised release commitment. If what you want is the Privnote/Bitwarden-Send flavour instead (share a secret that self-destructs after the recipient reads it), use Encrypted Send.
What is Encrypted Send?+
Encrypted Send is Flowvault’s one-shot sharing primitive — the tool you reach for when you need to hand someone a password, an API key, a recovery phrase, a piece of medical info, or any snippet you’d rather not leave sitting in Slack / email / a password-reset thread. Paste the note at /send/new, pick how long it should live (up to 30 days) and how many times it can be opened (default: once), and share the link. After the final view, the ciphertext is hard-deleted from our database— the scheduled sweep also purges anything past its TTL.
How does Encrypted Send protect the note?+

Four layers:

  1. Your browser generates a random 256-bit AES key and encrypts the plaintext with AES-256-GCM (authenticated encryption, so tampering is detectable).
  2. The key is placed in the URL fragment (after #). Browsers never send URL fragments to servers, so our database sees only the opaque ciphertext — we have no way to decrypt it.
  3. Optionally, you can add a password. The plaintext is then wrapped in an innerAES-GCM layer keyed by Argon2id(password) before the outer AES wrap. Same “FVPW” frame we use for time-locks.
  4. The server enforces the view counter atomically through a Cloud Function: reads go through readSend, which decrements the counter in a transaction and deletes the document the moment the last view is consumed. Firestore rules deny direct reads by clients — that’s what makes the counter trustworthy.
How is Encrypted Send different from Bitwarden Send, Privnote, or 1Password’s share link?+
Same general idea — a one-shot encrypted link — but different trust anchors and packaging:
  • Bitwarden Sendis excellent and also zero-knowledge, but it’s gated behind a Bitwarden account (for the sender) and closed server code for the receive path. Flowvault’s equivalent is account-less and open source end-to-end — frontend, Cloud Functions, and Firestore rules all live in the same repo.
  • Privnote is account-less too, but closed-source; you take its claims on trust. It also lacks an optional password gate, so a leaked link is game over.
  • 1Password Sharerequires a 1Password account for the sender and shares through 1Password’s infrastructure. Fine if you already live there.
  • Flowvault Encrypted Send: no account, open source, optional password gate using the same Argon2id + AES-GCM construction as the rest of the product, hard-delete on last view, Firestore TTL as a belt-and-suspenders sweep, and it lives next to your vault and time-locks under one URL.
Could Flowvault read my Encrypted Send note if you wanted to?+
No. The ciphertext goes to Firestore, but the 256-bit AES key lives in the URL fragment, which browsers never transmit. Anyone with access to our database — us, a cloud provider, a subpoena — sees only opaque bytes. If the sender also enabled a password, even leaking the URL isn’t enough to read the note. If you’re going to trust-but-verify any of this, the crypto is in src/lib/send/crypto.ts and src/lib/crypto/passwordFrame.ts, the Cloud Function is in functions/src/index.ts, and the rules are in firestore.rules.
What if someone intercepts the link before the recipient opens it?+
Whoever opens it first wins, and subsequent opens see “already opened” — which is actually a tripwire: if your recipient clicks the link and sees that message, you know the channel was compromised and can rotate whatever secret you shared. If that tripwire isn’t enough for your threat model, tick “Also require a password to open”. The recipient then needs both the link and the password, shared through different channels (e.g. link by email, password by phone / Signal).
Does Encrypted Send support files or just text?+
Text only for now. Plaintext is capped at 128 KiB — plenty for credentials, recovery phrases, configs, a long paragraph of context. File attachments are on the roadmap and would use Firebase Storage with a similar URL-fragment-keyed wrap; they’ll ship when we can do it without bloating the threat model.
What happens when an Encrypted Send note expires?+
An hourly Cloud Function (sendsSweep) batch-deletes any send past its expiresAttimestamp, and a Firestore TTL policy on the same field provides a secondary sweep. Whichever runs first wins; both are idempotent. Once the document is gone, even if someone saved the URL they see “not found” — Flowvault has no backup of deleted sends.

Using Flowvault

I forgot my password. Can I recover my notes?+
No. That's the whole point. There is no “reset” link because there is no copy of your key anywhere. Write your password somewhere safe.
Can two people share a vault?+
Yes. Share the URL and the password over a trusted channel. Both people can read and edit. If they edit at the same time, the second writer gets a conflict error instead of overwriting the first — so you won't silently lose data.
How big can a notebook be?+
Each slot holds around 8 KiB of text (roughly 1,500 words) in the default configuration, shared across all the tabs you create for that password. A single vault holds 64 slots for a total of 512 KiB. Spreading one notebook across multiple slots for longer content is on the roadmap.
Can I have multiple notebooks under one password?+
Yes. Each password unlocks a workspace of tabs, not a single page. Click + New above the editor to add a tab, double-click (or hover and click the pencil) to rename, drag tabs to reorder, and click the × to delete. All tabs — their titles, order, and contents — live inside the same encrypted slot, so the server sees one opaque blob the same as before. The tab list itself is zero-knowledge: nobody who does not have your password can tell how many tabs you have or what they're called.
If I add tabs, can someone with my decoy password see them?+
No. Decoy passwords land in their own separate slot with their own tab set. Adding or deleting tabs in your real notebook does not touch the decoy's slot at all — and vice versa. From the server's perspective the ciphertext blob is a fixed size no matter how many tabs exist in any slot, so the tab count is not even observable as metadata.
Can I use Flowvault offline?+
Not yet. A PWA / offline mode with local-first sync is on the roadmap.
Can I add a decoy password to an existing vault?+
Yes. Open your vault, click Add passwordin the editor toolbar, and pick a new password. Optionally seed the new notebook with some initial content (useful if it's meant to look ordinary when handed over under coercion). Each password unlocks its own notebook; nobody — not us, not an adversary with a copy of your blob — can tell how many you have.
What happens if two passwords collide on the same slot?+
Each password hashes into one of 64 slot positions. The chance of two independent passwords landing on the same slot is about 1/64(~1.6%). For three passwords it's ~4.7%; for five, ~14%. On collision one notebook overwrites the other — we cannot detect collisions across passwords without storing metadata that would break deniability. The one case we docatch: Flowvault refuses to register a new password whose slot would overwrite the notebook you currently have open. If collisions matter for your threat model, just pick a different password and try again.

Markdown preview & syntax-highlighted code blocks

Does Flowvault render Markdown?+
Yes. As of v1.3, every notebook renders as GitHub-flavored Markdown in a Preview or Split view. A small segmented toggle in the editor toolbar flips between Edit, Preview, and Split; the textarea is still the source of truth and your notes are still plain text under the hood. Preference persists per device in localStorage (not in the encrypted blob, so it doesn't eat into your 512 KiB slot).
Which Markdown flavor / features are supported?+
GitHub-flavored Markdown via react-markdown + remark-gfm:
  • Headings (# … ######), paragraphs, line breaks
  • Bold, italic, strikethrough (~~like this~~)
  • Ordered and unordered lists, including GFM task lists (- [x] done)
  • Tables, blockquotes, horizontal rules
  • Inline code and fenced code blocks with per-language Prism syntax highlighting (ts,py, rs, go, bash, json, and the rest of the usual crew)
  • Autolinks (<https://…>) and standard [label](url) links
  • Images, with the safety gate described below

The preview ships without Mermaid diagrams or KaTeX math on purpose — both would pull in large extra bundles for a niche use case. If you need either, let us know via GitHub.

Is the Markdown preview zero-knowledge too?+
Yes. Rendering happens entirely in your browser, after the slot is decrypted locally. Flowvault's server sees only the same opaque ciphertext as before — it never sees your Markdown source or the rendered HTML. The renderer bundle (~90 KB) is lazy-loaded via next/dynamic, so even the decisionto use Markdown isn't reported to anyone: users who stay in Edit mode never download it.
Why can't I embed <script>, <iframe>, or arbitrary HTML in my notes?+
By design: raw HTML is blockedin the preview. Anything that looks like an HTML tag renders as literal text, not as an element. There is no toggle to enable raw HTML, and there won't be.

Two reasons. First, Flowvault's whole value prop is “the server cannot read your notes.” That guarantee collapses the moment a rendered <script> tag can exfiltrate your plaintext back out of the browser. Second, vaults can be handed over (trusted handover) or imported from a .fvaultsomeone sent you; rendering arbitrary HTML from a notebook you didn't author is self-XSS waiting to happen. Keeping Markdown strict keeps the feature safe for beneficiaries and anyone collaborating via shared URL too.

Why do external images show a "Load image" button instead of just appearing?+
Because a Markdown image is an HTTP request, and an HTTP request is an opportunity to leak data. A hostile author (or someone who coerced a beneficiary's vault into their own hands, then returned it) could drop ![](https://attacker.example/pixel?v=target) into your notes, and the moment you unlocked the vault with preview enabled, your IP / user-agent / exact-to-the-second timing would ping their server.

Flowvault blocks that quiet channel. External images render as a placeholder showing the exact URL they would load, with a Load imagebutton that explicitly notes “sends a request to the host.” You get full informed consent before any pixel crosses the network, and when you do load it we still set referrerPolicy="no-referrer", so the host never learns which Flowvault URL or local vault was the source.

Inline base64 data:images render immediately, because they're part of the vault bytes — no network request, no leak.

What about external links — do they leak my vault URL as the referrer?+
No. Every external link the preview renders is hardened with target="_blank", rel="noopener noreferrer", and referrerPolicy="no-referrer". The destination site sees a normal click but cannot tell it came from Flowvault, let alone which slug or local file.
Does syntax highlighting hit the network?+
No. Code blocks are highlighted locally by prism-react-renderer, which ships as part of the lazy-loaded preview bundle. No remote theme fetch, no WebAssembly download, no “pick a language on first render” round-trip. Flowvault's no-third-party posture extends to the rendering layer.
Can I still edit my notes as plain text?+
Yes — the textarea is the editor. Markdown is just a viewover the same bytes. Switching between Edit, Preview, and Split doesn't change what gets saved; it changes what you see. If you never touch the toggle, Flowvault works exactly like before, and your .fvault backups and plaintext .md / .zip exports are identical byte-for-byte.
Does Split view work on my phone?+
Below ~900 px viewport width, the Split toggle hides automatically and Split collapses to Preview (or Edit, whichever you last chose). Your preferencestays “split” so resizing back up to a wide viewport restores the layout without you toggling again. The textarea and preview both scroll independently so the experience on narrow screens is at least usable.
Is there a WYSIWYG Markdown editor?+
No, intentionally. A live WYSIWYG layer would mean shipping a much bigger dependency (TipTap / ProseMirror / Lexical) and would blur what's actually getting encrypted. One of Flowvault's design properties is “your notes are plain Markdown text, not a proprietary JSON tree” — which keeps export portable and keeps the serialisation simple. Edit / Preview / Split is the compromise that gives you rendering without hiding the source.

Bring Your Own Storage (local .flowvault files; S3 / WebDAV on the roadmap)

What is Bring Your Own Storage (BYOS) in Flowvault?+
A mode where the vault's ciphertext doesn't live on our servers at all. You pick a file on your own disk — say D:\notes\journal.flowvault— and every save writes the encrypted blob back to thatfile via your browser's File System Access API. Same hidden-volume format, same Argon2id + AES-256-GCM, same multi-notebook tabs as a hosted vault. Flowvault just becomes the editor; your disk is the database.
How is BYOS different from the hosted Flowvault vault at /s/<slug>?+
The cryptography is identical — same slots, same KDF, same AES-GCM frames, same .fvault backup format. The difference is where the ciphertext lives:
  • Hosted vault: useflowvault.com/s/<slug>. The ciphertext is stored in our Firestore. Shareable URL. Works from any device. Trusted handover and all server-dependent features work.
  • Local vault: useflowvault.com/local/<uuid>. The ciphertext is a .flowvault file on your disk. Only openable on a device that has the file. The URL on its own is useless without the file. Trusted handover is not available because it needs a server-held scheduler.
What does your server see for a local vault?+
Essentially nothing that relates to the vault itself. The URL /local/<uuid>is just a client-side route; the UUID is generated in your browser, never posted back, and the Next.js server doesn't know which file (if any) it corresponds to. Your browser never uploads the ciphertext or the file name to us. The one caveat is the editor chrome: if you use server-dependent features while a local vault is open — time-locked notes composition, Encrypted Send — those specific flows still talk to our backend for their own documents (a time-locked capsule, a send record), same as they would from a hosted vault. They never see your local vault's plaintext or ciphertext.
Which browsers support local vaults?+
BYOS relies on the File System Access API, currently available in Chromium-based browsers (Chrome, Edge, Brave, Opera, Vivaldi, Arc) on desktop. Firefox and Safari don't implement it yet, so the “Create / Open local vault” buttons are disabled there with a note. A hosted vault at /s/<slug> still works in every browser. Mobile support for the API is spotty; we treat desktop Chromium as the supported surface for now.
What's inside a .flowvault file on disk?+
A small JSON header (format version, a per-file UUID, the Argon2id salt, KDF parameters, volume layout, a monotonic vaultVersioncounter used for optimistic concurrency, and timestamps) followed by the raw ciphertext — the same fixed-size hidden-volume blob that would live in Firestore for a hosted vault. No passwords, no derived keys, no plaintext, no per-slot metadata. Opening the file in a text editor will just show you the JSON preamble and then binary noise. If a copy of the file leaks, an attacker has to do exactly the same offline brute-force work they'd face against a stolen Firestore document — nothing more, nothing less.
How do I move a local vault between devices?+
Copy the .flowvaultfile. That's the whole state — put it on a USB stick, sync it through your cloud of choice, email it to yourself encrypted, whatever fits your threat model. On the other device, open Flowvault, click Open local vault, point at the copied file, and enter your password. The file is self-contained: everything the editor needs (salt, KDF params, volume layout, slots, CAS version) travels with it.
What if I edit the same local vault from two devices?+
Each save is gated by an optimistic CAS counter that lives inside the file, so you won't silently clobber the other side: whoever writes first wins, and the second writer sees a conflict. That said, BYOS is not a sync engine. If both devices edit the same vault without coordinating, you have the usual merge problem of any file-backed tool. The safe patterns are (a) edit in one place at a time, or (b)keep separate vaults on separate devices and merge manually. A proper sync story (conflict-free, offline, auto-resolving) would need a different backend — see the S3 / WebDAV question below.
Does trusted handover work on local vaults?+
No — and this is intentional. The trusted handover relies on a Cloud Function running on a schedule to mark a vault released after an inactivity interval, which only makes sense for a document that lives in the hosted Firestore. A local file sitting on your disk has no server watching it. If you want the handover behavior, use a hosted vault at /s/<slug>. The editor hides the Handover button for local vaults so it doesn't suggest a guarantee we can't keep.
What about time-locked notes and Encrypted Send from a local vault?+
Those still work — they have nothing to do with where your vault lives. Composing a time-locked note or an Encrypted Send from the editor stores the one-shot capsule / send document in our backend the same way as always; only the notebook text lives in your local file.
How is this different from the .fvault backup file?+
A .fvault is a point-in-time snapshot, taken by clicking Export. A .flowvault is the live vault— every save in the editor writes through to that file, same as a hosted vault writes through to Firestore. You can still export a .fvault from a local vault for cold storage, or restore from a .fvault into a hosted vault at /restore. The two formats are siblings: same ciphertext, different roles.
What happens if I lose my .flowvault file?+
Your notes are gone. There is no copy on our servers. Treat the file the way you treat a password manager's local database or a VeraCrypt volume: back it up. An easy rhythm is a periodic .fvaultexport into a separate folder or cloud drive — the export is still zero-knowledge, still needs your password, so it's fine to store in places you wouldn't trust with plaintext.
Are S3, WebDAV, and other storage backends coming?+
Yes, on the roadmap if there's demand. The internal storage layer was refactored into a VaultStorageAdapter interface specifically so new backends plug in cleanly; the local-file adapter was the first non-Firestore implementation. Likely next candidates, in rough order:
  • S3-compatible (AWS S3, Cloudflare R2, Backblaze B2, Wasabi, MinIO). Good for people who want their ciphertext in an object store they already pay for, with versioning turned on.
  • WebDAV (Nextcloud, ownCloud, Storj-compatible gateways). Same idea, different wire format; easy to self-host.
  • IPFS / Storj / Arweave for fully decentralised storage, treated as a more experimental tier.

All of these would follow the same rule as local files: the blob stays opaque, the adapter just moves bytes, and server-dependent features (trusted handover, hosted routing) stay on Flowvault. If a specific backend is a blocker for you, please open a GitHub issue and say so — prioritisation is driven by who actually wants to use it.

Backup, restore & migration (.fvault, Markdown export, self-hosting)

Can I back up my Flowvault notes?+
Yes. Open any vault and click Export → Encrypted backup (.fvault)in the toolbar. You get a single file containing the full ciphertext blob plus the Argon2id salt, KDF parameters, and volume layout — exactly what the server stores. The backup is still zero-knowledge: reading it requires your password, and every decoy slot remains indistinguishable from random bytes inside it. Restore later from /restore on this instance or on a self-hosted Flowvault.
Is the .fvault backup file itself encrypted?+
Yes. The ciphertext inside the backup is the same AES-256-GCM ciphertext the server holds, still keyed by Argon2id over your password and the per-vault salt. If a backup file leaks, an attacker has to do the same offline brute-force work they'd do against a stolen Firestore document — nothing more, nothing less. The thin JSON envelope around the bytes is plaintext, but it only carries metadata that the server already stores (salt, KDF params, volume layout, slug hint), so the file isn't any more revealing than a copy of the database row.
How do I restore a Flowvault backup?+
Go to /restore, drop your .fvault file, pick a fresh URL, and click Restore vault. We write the ciphertext and its original KDF/volume metadata into Firestore under that new slug. You never type a password during restore — there's no decryption happening server-side. Once the site exists, open it as normal and enter the password(s) you used before. Every slot (every decoy password) comes back intact.
Why does restore block me from overwriting an existing vault?+
Safety. Restoring onto an existing slug could silently destroy a notebook under a password you don't know about. We intentionally refuse rather than ask you to re-authenticate, because proving knowledge of onepassword wouldn't prove knowledge of the others that might be hidden in the same blob. Pick a new slug, or start a fresh vault and migrate content manually.
Can I export my notes as plaintext Markdown for Obsidian, Standard Notes, or a git repo?+
Yes — the same Export menu in the editor has a Plaintext Markdown (.zip) option. Each tab in the currently-unlocked slot becomes one .md file in the zip, plus a README.mdindex. The export is limited to the slot you're looking at — other passwords' decoy slots are neverincluded, which keeps plausible deniability intact even if you're exporting under coercion. We also show an explicit confirmation before writing any plaintext to disk.
Does ProtectedText have an export / backup feature?+
Not out of the box. ProtectedText has no export button, no API, and no backup file — the closest you can get is unlocking the note in the browser and manually copying the text. Flowvault's .fvault backup preserves your notes encrypted, so you can store copies on a USB stick, in another cloud, or on a friend's machine without ever exposing plaintext. If you want to migrate into Flowvault from ProtectedText today, the practical path is: unlock your note there, copy the text, paste it into a new Flowvault notebook. A guided importer is on the roadmap.
Can I self-host Flowvault and move my backups there?+
Yes. The whole stack — Next.js frontend, Cloud Functions (the trusted-handover release sweep and the Encrypted Send read path), and Firestore security rules — is in one public repository. Bring your own Firebase project, deploy the rules and Functions, point the frontend at it, and drop a .fvault file onto /restore. Because the backup format includes the KDF parameters and volume layout that produced the ciphertext, vaults made on the hosted Flowvault will open on your self-hosted one with the same password.
What exactly is inside a .fvault file?+
A single JSON envelope with these fields:
  • kind = "flowvault-backup" and version (currently 1).
  • exportedAt and an optional slugHint so the restore UI can prefill a sensible URL.
  • kdfSalt(base64url) — the per-vault Argon2id salt.
  • kdfParams— algorithm (argon2id), memory cost, iteration count, parallelism, key length.
  • volume— slot count, slot size, and frame version.
  • ciphertext(base64url) — the fixed-size hidden-volume blob, byte-for-byte identical to what lives in Firestore.

No passwords, no keys, no plaintext, no per-slot metadata. You can inspect any .fvault with a plain text editor to verify that for yourself.

Do other encrypted notepads have a zero-knowledge backup format?+
Most have some export, but usually as plaintext:
  • Standard Notes exports to a JSON/zip of plaintext items (optionally into an encrypted archive on Plus/Pro). An account is required.
  • CryptPad has per-pad exports to .md / .html/ raw — all plaintext.
  • Bitwarden exports to plaintext JSON/CSV (or a password-protected JSON variant; the secret is chosen at export time, not derived from your vault password).
  • Notesnookexports encrypted backups (.nnbackup) behind an account and subscription, parallel to Flowvault's.fvault in spirit.
  • ProtectedText / Privnote / PrivateBin: no export feature at all.

Flowvault's angle is that the backup is the same ciphertext you already trust on our server, with no account tying it to you. Handing the file to a stranger is no worse than handing them your URL.

How often should I back up?+
Flowvault backups are only as fresh as the moment you downloaded them, so treat them like snapshots, not live mirrors. A reasonable rhythm: one backup after any major edit you can't afford to lose, plus a monthly rolling snapshot if you use the vault for long-form notes. The file is ~680 KiB regardless of how much you've written (fixed-size ciphertext), so storing many snapshots is cheap. Some users pair this with a trusted handover: the backup protects against data loss, the handover against you being unable to unlock it.

Project

Who builds Flowvault?+
Flowvault is part of the Flowdesk family of tools. It's built in the open; contributions and security reviews are welcome.
Is Flowvault open source? How does that compare to ProtectedText?+
Yes — and importantly, the whole stack, not just the frontend bundle. Three things are published together in the same repository:
  • Frontend (Next.js, all UI + client-side crypto)
  • Cloud Functions(the trusted-handover release sweep). You can read exactly what server-side code runs on your behalf — there is no hidden server process.
  • Firestore security rules(the actual boundary that keeps us from reading your data). These are short, auditable, and enforced by Google's infrastructure.

You can self-host the entire stack: bring your own Firebase project, deploy the rules and Functions, point the frontend at it. A permissive license (MIT planned) lets you fork it freely.

For comparison: ProtectedTextpublishes its client-side JavaScript so you can read it in the browser (commendable, and they encourage it), but their FAQ explicitly states “we haven't opened the server code for now.” They argue the server is irrelevant because all crypto happens in the client — which is a fair argument, but you still can't self-host their service or audit what their server does with your encrypted blobs (rate-limiting, logging, retention). Flowvault's answer is to put the server code, the database rules, and the deployment config in the same repo, so there is nothing to take on faith.

How is Flowvault funded?+
Donations and personal time. We don't run ads, don't sell data, and don't have a paid tier (yet). The project intentionally doesn't have the usual revenue levers because those levers tend to be the opposite of privacy. Hosting, domain, and drand beacon monitoring costs come out of pocket and out of donations.
I want to support Flowvault. What helps?+
Crypto donations are the main channel. The /donate page embeds the NOWPayments donation widget: pick any of ~100+ coins (Bitcoin, Ethereum, Litecoin, Monero, USDT on TRC-20 or ERC-20, Solana, and many more), the widget generates a one-time deposit address, and your wallet sends funds directly. No donor sign-up, no email required. Even the equivalent of a coffee genuinely helps.

Not in a position to donate? Use Flowvault, tell someone who needs it, star the GitHub repo, file a bug, or submit a PR. All of those matter just as much.
Why crypto instead of a regular card or PayPal?+
Because every traditional payment rail asks for identifying information — card number, email, billing address, country — which defeats the point of a zero-knowledge product. Accepting crypto lets us receive your support without also receiving a dossier on you. If crypto is a non-starter for you, we're not offended; please just don't feel pressured.
Why NOWPayments specifically, and what does it see about me?+
NOWPayments' donation widget is one of the few processors that lets a donor contribute without creating an account or providing an email— receipts are optional and only needed if the donor wants one. It also generates a fresh deposit address per donation, so later donors can't cross-reference each other on-chain. On our side we just receive the forwarded funds.

What NOWPayments sees on the donor side: your IP and your browser when you interact with their widget (same as any website you load). They don't require an email, and they don't require KYC for a donation. If that isn't private enough for you, load the page through Tor or a VPN — both work — and send Monero, which hides amount and identity at the protocol level. We don't receive any of that metadata either way.
Which coin should I send?+
If privacy is paramount, send Monero (XMR). Every other major chain — Bitcoin, Ethereum, Litecoin, USDT, Solana — is pseudonymous: the full history of transactions to an address is public, so anyone who ever learns a donation address later can see the full ledger. Monero hides amounts, senders, and receivers by design. For low fees on stablecoins, USDT on TRC-20 (Tron) is a good choice.
How do I report a security issue?+
Please use GitHub security advisories or email the maintainer privately before public disclosure. We'll credit responsible disclosures.

Want a longer answer?

The Flowvault blog has feature-by-feature deep dives: the hidden-volume format, the trusted handover, drand-backed time-locked notes, an honest Flowvault vs ProtectedText head-to-head, a head-to-head of Encrypted Send vs Bitwarden Send vs Privnote, the .fvault backup format, a beginner's guide, and why Flowvault exists in the first place.