Flowvault 1.2.0 — Bring Your Own Storage

Flowvault started as "an encrypted notepad at a URL." 1.2.0 keeps that,
and adds the other end of the spectrum: an encrypted notepad that
lives as a single file on your own disk, with Flowvault acting only
as the editor.

No account. No server-side copy of the ciphertext. No upload on save.
Same hidden-volume format, same Argon2id + AES-GCM, same multi-notebook
tabs — just written straight to D:\notes\journal.flowvault (or
wherever you point it) via your browser's File System Access API.

This is the first non-Firestore backend. The storage layer was
refactored into a VaultStorageAdapter interface specifically so more
can follow — S3-compatible (R2 / B2 / Wasabi / MinIO) and WebDAV are
next on the roadmap if there's demand.

Highlights

🗄️ Bring Your Own Storage — local .flowvault files

• Create or open a local vault straight from the home page. Pick a
  file, set a password, start writing. The editor opens at
  /local/<uuid> and every save round-trips to the file on disk.
• Single-file format. The .flowvault file is a tiny JSON header
  (format version, per-file UUID, Argon2id salt, KDF parameters, volume
  layout, a monotonic CAS counter, timestamps) followed by the raw
  fixed-size hidden-volume blob. Byte-for-byte the same ciphertext that
  would live in Firestore for a hosted vault.
• Multi-notebook tabs, decoy passwords, .fvault backup, and
  plaintext Markdown export all work the same way they do on hosted
  vaults. Only trusted handover is (by design) disabled for local
  vaults — it needs a server-held scheduler, and a file on your disk
  has no server watching it.
• Zero server involvement for vault I/O. The server never sees the
  ciphertext, the file path, the file name, or the UUID — the
  /local/<uuid> route is entirely client-side and the UUID is
  generated in your browser.
• Optimistic concurrency still works. Each save is gated by a CAS
  counter inside the file; two devices writing to the same file get a
  conflict instead of a silent clobber.
• Portable. Copy the file (USB stick, cloud sync, encrypted email —
  whatever fits your threat model). On the other device, click
  Open local vault, point at the copied file, enter your password.
  Everything travels with the bytes.
• Browser support. Chromium-based desktops today (Chrome, Edge,
  Brave, Opera, Vivaldi, Arc). Firefox and Safari don't implement the
  File System Access API yet, so the buttons disable themselves with
  a note on those browsers. Hosted vaults at /s/<slug> still work
  everywhere.

🔌 Pluggable storage layer (VaultStorageAdapter)

Internally, every vault-blob read/write now goes through a per-site
storage adapter. The Firestore backend is one implementation, the
local-file backend is another, and the dispatcher picks the right one
based on the route you're on. This is the groundwork for:

• S3-compatible backends (AWS S3, Cloudflare R2, Backblaze B2,
  Wasabi, MinIO) — great for people who want versioned object storage
  they already pay for.
• WebDAV backends (Nextcloud, ownCloud) — good self-hosting story.
• Experimental decentralised backends (IPFS / Storj / Arweave).

All of those will follow the same rule as the local-file adapter: the
blob stays opaque, the adapter just moves bytes, and server-dependent
features (trusted handover, hosted routing) stay on the Flowvault
Firestore backend. Prioritisation is driven by demand — please
open a GitHub issue
if a particular backend would unblock you.

📄 MIT license, officially

Flowvault has always intended to be MIT, but the license wasn't spelled
out in the repository. 1.2.0 fixes that: there's now a top-level
LICENSE file with the standard MIT text, and package.json declares
"license": "MIT". Nothing changes about how you can use or fork the
project — this is just paperwork catching up to reality.

Smaller changes

• Editor chrome is BYOS-aware: a local vault shows
  local: journal.flowvault instead of /s/<slug> in the toolbar,
  and the Handover button is hidden (rather than disabled) for local
  vaults so it doesn't promise something we can't deliver.
• Password gate has optional displayOverride and
  descriptionOverride props, used by the local-vault screen to say
  "Enter the password for <filename>" instead of referencing a URL
  slug that doesn't apply.
• Plaintext Markdown export works on local vaults too. The README
  index inside the zip says "local vault" instead of /s/<slug> when
  there isn't one.
• Export menu and filename suggestions now accept nullable slugs
  cleanly (vault.zip fallback for BYOS).
• Zustand vault store extended with storageKind, nullable slug,
  and displayLabel — the "one URL, one vault" assumption that was
  baked into a lot of UI code has been lifted.
• IndexedDB-backed handle registry keeps FileSystemFileHandle
  references around between sessions so that reopening a local vault
  is one click + a browser permission prompt, not a full re-pick from
  disk. (Handles are origin-scoped and permission isn't persisted by
  the browser, so you'll always see a permission prompt on the first
  save of a new session — that's the web platform, not us.)

Docs & SEO

• New FAQ section: Bring Your Own Storage (local .flowvault files;
  S3 / WebDAV on the roadmap) with 12 Q&As covering what BYOS is,
  what the server sees for local vaults, browser support, the on-disk
  file format, moving between devices, two-device edits, why trusted
  handover is intentionally disabled for local vaults, how
  time-locked notes and Encrypted Send still work, .flowvault vs
  .fvault, what happens if you lose the file, and the S3/WebDAV
  roadmap.
• Home page gets a new Bring your own storage feature card and a
  row in the Flowvault vs ProtectedText comparison table.
• README adds a BYOS bullet, a row in the security table, and a
  reshuffled roadmap (local file: shipped; S3 / WebDAV / IPFS: planned).
• SoftwareApplication JSON-LD now advertises BYOS in featureList.

Threat-model notes

BYOS genuinely reduces what our backend can see about you — for local
vaults, the ciphertext and metadata never reach us at all. But it
doesn't change your local threat model: a .flowvault file sitting on
your disk is still a file on your disk, subject to the usual forensic
risks (shadow copies, cloud-sync providers, file-system journaling).
If that's part of your threat model, store the file on an encrypted
volume (VeraCrypt, LUKS, FileVault) the same way you would any other
sensitive file.

A full writeup will land as a blog post:
flowvault.flowdesk.tech/blog/bring-your-own-storage-local-vaults.

Upgrade

No action required. Existing hosted vaults are unchanged — same slugs,
same URLs, same pass