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

How to use Flowvault: a complete beginner's guide to zero-knowledge notes

From your first URL to decoy passwords, trusted handovers, time-locked notes, Encrypted Send, and encrypted backups — step by step.

The fastest way to learn Flowvault is to open it and type. This guide covers the same ground you would hit by exploring, in the order most people actually need things: your first vault, how saving and tabs work, when to add a decoy password, and how to reach for the trusted handover, time-locked notes, Encrypted Send, and encrypted backups when the situation calls for them.

Step one: your first vault

Go to flowvault.flowdesk.tech. You'll see a single input box that expects a URL slug — something like my-notes or project-alpha. Type anything lower-case, hit Open, and Flowvault will either:

  • Load the existing vault if someone already registered that slug (in which case you need their password to decrypt it), or
  • Offer to create a new vault if the slug is free — just set a password, confirm, and you're in.

The slug you picked becomes a permanent URL (e.g. flowvault.flowdesk.tech/s/my-notes). Bookmark it, or just remember it — the point of the slug-plus-password design is that a bookmark isn't required.

Step two: writing and saving

The editor is a single pane of plain text with Markdown awareness. Type anything; saves happen automatically, in the background, debounced by around a second after you stop typing. The status badge in the top bar shows one of three states:

Saving…
Flowvault is currently re-encrypting the whole notebook with your master key and uploading the new ciphertext blob.
Saved
The server has acknowledged the write and bumped the version counter. If you have a trusted handover configured, this save also counts as a heartbeat.
Error
Either the network dropped, another tab edited the same vault (optimistic-concurrency conflict), or the server rejected the write (for example because the handover fired while you were editing). The banner suggests the fix.

You can also hit the Save button to flush immediately, or the Lock button to clear the key from memory and return to the password prompt without closing the tab.

Tabs: many notebooks under one password

Click + New above the editor to create a tab. Double-click (or hover + pencil icon) to rename, drag to reorder, and click the ×to delete. Every tab is part of the same encrypted slot, so the server sees one opaque blob whether you have one tab or twenty. Tab titles themselves are zero-knowledge — nobody who doesn't have your password can tell how many tabs you have or what they're called.

Step three: adding a decoy password

This is the flagship feature and the one no other browser notepad offers. The design principle: one URL holds up to 64 independent notebooks, each behind a different password, and nobody can tell how many exist. The deep mechanics are in the hidden-volumes deep dive; the UI is simple.

  1. Open the vault under your real password so you have the master key in memory.
  2. Click Add password in the editor toolbar.
  3. Enter a new password (the decoy one). Optionally seed the new notebook with initial content so it looks ordinary if handed over under coercion.
  4. Click confirm. Flowvault writes a new slot, encrypted under an independent key, and leaves your current notebook untouched.

From now on, the same URL accepts either password. Each one unlocks its own notebook. The server can't tell there are two notebooks. An attacker with a copy of the ciphertext can't tell either — the unused slots are indistinguishable random bytes.

Step four: trusted handover (for inheritance)

If nobody inherits your notebook when you're hit by a bus, it's gone. The trusted handover is the answer: pick a beneficiary password, give it to someone you trust out of band, and configure an inactivity interval. If you stop saving for that interval plus a grace period, the vault becomes readable to the beneficiary. The full crypto is in its own post; the UI flow:

  1. In the editor toolbar, click Handover (clock icon).
  2. Pick one of the presets — weekly / monthly / quarterly / yearly check-in cadences — or set a custom interval and grace period.
  3. Choose a beneficiary password at least 12 characters long. This is a differentpassword from your own; it's the one you'll give to the person who inherits.
  4. Click Enable trusted handover.

Share the beneficiary password with your trusted person over something sturdy — a sealed envelope, a password manager's share link, an in-person conversation — and tell them the URL. From then on, every save counts as a check-in. If you go quiet past the interval plus grace, an hourly Cloud Function marks the vault released and the beneficiary password starts unlocking it.

Step five: Encrypted Send (one-shot secrets)

Use case: you need to hand someone a password, a recovery phrase, or a short piece of sensitive info, and you'd rather not leave it in Slack or email. The detailed comparison against Bitwarden Send and Privnote is in this post; the how-to:

  1. Go to /send/new.
  2. Paste the secret (up to 128 KiB of plaintext).
  3. Choose how long it should live (up to 30 days) and how many times it can be opened (default: once).
  4. Optional: tick “Also require a password to open,” which adds an Argon2id-gated second layer. Share the password over a different channel from the link.
  5. Click Create link. You get a URL that looks like flowvault.flowdesk.tech/send/<id>#k=<key>. The #k=... fragment is the AES-256 key; your browser never sends it to the server.

When the recipient opens the link, a Cloud Function decrements the view counter in a transaction and hard-deletes the document when the last view is consumed. Firestore rules deny direct reads by clients, so the counter is trustworthy — not a suggestion.

Step six: time-locked notes (messages to the future)

These are complementary to the trusted handover. A handover releases a vault if you go quiet. A time-locked note releases a message if a future date arrives, and not before — not even to the sender. The mechanism uses the drand randomness beacon and tlock identity-based encryption, detailed in the time-lock post. The UI:

  1. Visit /timelock/new.
  2. Compose your message (up to 128 KiB).
  3. Pick an unlock moment. Anything from a few minutes out to decades; the granularity is 30 seconds.
  4. Optional: tick “Also require a password to read” to layer an Argon2id-keyed inner wrap around the time-lock. The reader then needs both the link and the password, and both gates arrive independently.
  5. Click Create time-lock and share the resulting flowvault.flowdesk.tech/t/<id>link. Opening it before the unlock moment shows a countdown; after, the reader's browser grabs the drand round signature and decrypts locally.

Step seven: encrypted backup

Once you've got content you care about, take a snapshot. Open the vault and use the Export menu in the toolbar, which offers two options. The format is documented in detail in the .fvault post; the short version:

  • Encrypted backup (.fvault)— a single file containing the same ciphertext blob the server stores, plus the Argon2id salt and KDF parameters. It's still zero-knowledge: reading it requires your password, and every decoy slot remains opaque. Preserves every password on the vault, tabs and all.
  • Plaintext Markdown (.zip)— behind an explicit confirmation, the current slot's tabs are written to .md files in a zip, with a README.md index. Only the slot you currently have unlocked is exported; decoy slots are never included, which preserves deniability even under coercion. This is the format to pick for migration to Obsidian, a git repo, or Standard Notes.

Restoring a backup

To restore, drop the .fvault file on /restore, pick a fresh URL slug, and click Restore vault. You never type a password during restore — there's no decryption happening server-side. Once the vault exists at the new slug, open it like any other and enter the original password(s). Restore refuses to overwrite an existing slug; pick a new one if yours is taken.

Working across two tabs or two devices

The same URL + password opens fine on as many devices as you like. If two people (or one person in two tabs) edit the same vault at the same time, the optimistic-concurrency check catches it: the second writer gets a conflict error instead of silently overwriting the first. Reload to see the latest version, then retry your edit.

This is also why reliable sharing works: give a trusted collaborator both the URL and the password, both of you can read and write, and neither of you will silently clobber the other's work.

Quick reference

Create / open a vault
Home page, type a slug, set a password.
Add a decoy password
Editor toolbar → Add password.
Enable trusted handover
Editor toolbar → Handover, pick interval and beneficiary password.
Send a one-shot encrypted note
/send/new.
Time-lock a message
/timelock/new.
Back up a vault
Editor toolbar → Export → Encrypted backup (.fvault).
Migrate to Obsidian / plaintext
Editor toolbar → Export → Plaintext Markdown (.zip).
Restore a backup
/restore, drop the .fvault file, pick a new slug.

Where to go next

If you're curious about what happens behind the UI, each feature has a deep-dive post:

Or take the security tour on /security, which lists the exact crypto primitives, parameters, and threat-model limits.

Related posts

Ready to try what you just read about?

Open a URL on the home page (no sign-up), send a self-destructing encrypted note, or seal a message for a future date at /timelock/new.