Flowvault FAQ

Yes. There's a live public demo at useflowvault.com/s/demo with two pre-loaded notebooks behind two different passwords, so you can feel the hidden-volume design work with your own eyes in about 30 seconds.

• CorrectPasswordopens the “real” notebook — a walkthrough plus example tabs for wallet seeds, API-key rotation, and a scratchpad.
• DecoyPasswordopens the decoy — a deliberately boring cover notebook (shopping list, recipes), shaped like what a plausible decoy actually looks like in the wild.

Same URL. Same ciphertext blob on our server. Two completely different screens. The blob is indistinguishable whether the other notebook is there or not — that's the whole deniability property, end-to-end visible without you having to pick a password of your own.

Trust boundary for the demo:the server rejects all writes at the demo URL. You can edit anything in your browser to poke around, but nothing you type is saved, shared, or visible to the next visitor — the vault resets the moment you close the tab. Don't put real secrets in it anyway — it is a public, credentialed walkthrough.

An honest shortlist — we'd rather you pick the right tool than convert you to the wrong one.

Pick Flowvault if: you want a browser-only encrypted scratchpad with no account, you want hidden-volume deniability (multiple passwords on the same URL unlock different notebooks), or you need an account-less self-destructing share link. Typical users: people replacing ProtectedText, people stashing wallet seeds / API keys / medical info, and people who want a decoy password for travel.

Pick something else if:you want a multi-device notes app — Standard Notes or Notesnook are excellent there. You keep long-form journals — Obsidian or Joplin handle volume better. You want real-time collaborative editing — use CryptPad. You're storing the onlycopy of a crypto wallet seed — use KeePassXC or a paper backup in a safe, and at most keep Flowvault as a second location for a split seed.

The realistic shape is: Flowvault complements a local-first app, it doesn't replace one. A lot of users end up running both.

Partially. Here's the honest matrix:

• The core hosted vault (/s/<slug>) works in every modern browser — iOS Safari, Android Chrome, desktop Firefox, desktop Safari. You can unlock, read, and write from a phone, it just isn't optimised into a standalone app experience.
• Bring Your Own Storage (local .flowvault files) requires the File System Access API, which today ships in Chromium-based browsers on desktop only (Chrome, Edge, Brave, Arc, Opera, Vivaldi). Firefox and Safari don't implement it yet; mobile support is spotty.
• There is no native app— no iOS app, no Android app, no Electron build. It is a deliberately server-agnostic web app. We may add a PWA with offline mode (it's on the roadmap), but native apps aren't on the near-term plan.

If mobile-first editing or offline-first workflow is a hard requirement, use Standard Notes, Notesnook, or Obsidian. Flowvault is a better fit as the “browser tab you open for one specific purpose” than as your daily driver for a 5,000-note knowledge base.

Depends on what you write. Concrete reference points:

• ~1,500 wordsof prose per slot, or roughly 4–5 tightly-written pages.
• A crypto wallet seed (24 BIP-39 words): ~150 bytes. You can store dozens of them per slot.
• A password manager exportof 300 short credentials: ~15 KiB. Doesn't fit in one slot, does fit across two tabs.
• A daily journal entryof 300 words: ~2 KiB. A slot is full after ~4–5 entries.
• A meeting-notes workflow (20 notes / month, 400 words each): ~40 KiB / month. A slot fills in 5 days.

Good rule of thumb: if you're writing reference material(credentials, recipes, how-tos, contact lists, TODO lists, one-off scratch), 8 KiB per slot × up to 64 slots is plenty. If you're writing log-style material(journal, meeting notes, daily standup), you'll hit the ceiling within weeks and the friction is real — use something built for that shape. Per-notebook limits can be raised in future vault versions (the on-disk format is already param-driven), but the current default is a tradeoff against keeping the fixed-size blob small enough to stay snappy on mobile connections.

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.

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.

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.

• 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.

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.

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.

• 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.

• 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.

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.

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.

• 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.

• A download link for the recipient (useflowvault.com/file/<id>#k=<key>).
• A secure delete link for you to keep (useflowvault.com/file/<id>/delete#t=<token>) — opening it lets you destroy the upload immediately, before the cap or expiry.

Optional password gate works the same way as Encrypted Send. Read the File Send deep dive for the full protocol walkthrough.

AES-256-GCM in your browser before any byte leaves your device. The exact key tree:

1. A random 256-bit key K is generated client-side. It travels in the URL fragment (#k=…); browsers never transmit fragments to servers.
2. If a password is set, an Argon2id key is derived from it (64 MiB / 3 iterations) and concatenated with K to form the base material.
3. Two HKDF subkeys are derived: a contentKey (used to AEAD-encrypt the file bytes, uploaded to Cloud Storage) and a metadataKey (used to AEAD-encrypt a small JSON blob with the filename, MIME type, and size, stored in Firestore).
4. A separate random 256-bit delete token is generated. The server stores only its SHA-256 digest; the raw token lives in your secure delete link, so possession of the link is the only thing that authorizes deletion.

Direct reads on the Storage object and the Firestore document are denied by rules. The only path to the bytes is readFileSend, a Cloud Function that atomically consumes a download in a Firestore transaction and returns a 5-minute v4 signed URL.

• The opaque ciphertext bytes in Cloud Storage at fileSends/<id> (file size + 28 bytes of AEAD overhead).
• A small encrypted metadata blob in Firestore (server can't open it).
• Expiry, max downloads, current download count.
• A boolean passwordProtectedflag and, when set, a 16-byte Argon2id salt — useless without the password and the URL fragment.
• The 32-byte SHA-256 of the delete token. Useless without the original token.

It does notsee the filename, MIME type, file content, AES key, password, delete token, or any account / email / persistent identifier — because none exist.

• The recipient consumes the final allowed download. The Cloud Function deletes the Firestore doc immediately and the scheduled fileSendsSweep drops the Storage object on the next tick (after the 5-minute signed-URL grace window expires).
• The expiry passes. fileSendsSweep deletes both the doc and the object on the next hourly run.

You can also force an immediate delete yourself by opening your secure delete link. The Cloud Function deleteFileSendSHA-256s the token from your URL fragment, compares it to the stored hash in constant-ish time, and (on match) drops the Storage object plus the Firestore document. We can’t recover the upload after that, and we can’t do this on your behalf because we never stored the raw token.

• 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.

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.

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.

• ProtectedText: no search. One password opens one blob and you scroll.
• Standard Notes, Notesnook: encrypted search, but it relies on a client-side index that's built and persisted locally (so a search surface outlives the session), and it's tied to an account.
• Obsidian, Joplin: local-first with excellent search — but over files on disk, not a deniable, server-hosted blob.

Flowvault's choice is deliberately minimal: the search “index” is just the plaintext of the slot you're already viewing, and nothing is written anywhere for it. You trade the ability to query locked slots for a property that's hard to match — search that can't survive a lock, can't be subpoenaed, and can't be exfiltrated as an index later.

• 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.

• 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.

• 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.

• 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.

• 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.