Available for hire — privacy-first apps, engineering, and business-idea work.contact@flowdesk.tech
Flowvault

Flowvault FAQ

Questions we get (or expect to get) about our zero-knowledge encrypted notepad, the dead-man's switch, drand-backed time-locked notes, 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 flowvault.flowdesk.tech/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.

Dead-man's switch & time-locked notes

What is the dead-man's switch?+
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 dead-man's switch 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 switch 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 deadman alive.
Can I cancel a dead-man's switch?+
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 switch 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 switch from a decoy notebook's session rather than from your primary one.
Do Standard Notes / ProtectedText / Privnote have a dead-man's switch?+
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. Flowvault ships the switch as a first-class, client-side feature.
Time-locked notes — are those the same as the dead-man's switch?+
No, they're complementary. The dead-man's switch 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 flowvault.flowdesk.tech/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 notebook (slot) holds around 8 KiB of text (roughly 1,500 words) in the default configuration. A single vault holds 64 slots for a total of 512 KiB. Multi-slot notebooks (spreading one notebook across several slots for longer content) are on the roadmap.
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.

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(dead-man's-switch 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?+
Direct crypto donations are the most privacy-safe way. The /donate page lists wallet addresses for Bitcoin, Ethereum, Litecoin, Monero, USDT (TRC-20 and ERC-20), and Solana — no sign-up, no email, no middleman. Your browser talks directly to the blockchain; we learn nothing about you. 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 not use Plisio, NOWPayments, or a similar crypto gateway?+
Because those gateways — even though they handle crypto — still collect a donor emailfor receipts, which contradicts Flowvault's whole pitch. Raw wallet addresses are the only way to accept money without learning anything about the sender. We display them as plain text and QR codes; your browser never makes a network request to a payment processor, because there isn't one.
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.