Your vaults are drives now — and you can write to them

This week has a headline I've wanted to write for a while: your vaults are drives now. Not "export to a folder," not "download, edit, re-upload" — a real mounted disk in your file manager that you can read and write, with the bytes living on the mesh.

Your vaults are drives now — and they take writes

Mount a vault and it shows up like any other disk: a lettered drive on Windows (via WinFsp, which the installer now offers to fetch for you), a normal mount on Linux (FUSE), a place in the Android Files app, or a WebDAV target for everything else. There's a meshhold mount command, a Drives section in the tray, and a "Mount as drive" button right on the vault card.

Reads stream on demand — open a 4 GB video off the drive and it pulls only the blocks you're actually watching, not the whole file. That part shipped first; it was the easy half.

The hard half was writes, and that's where most of the week went. Mounts take writes everywhere now: drag a file onto the drive and it's chunked, encrypted, and replicated into the vault behind the scenes; you can rename, make folders, edit a stored file in place, and on Android save straight into a vault from any app's share sheet. Getting there meant teaching the write path a few things a normal filesystem takes for granted — accepting a file whose final length you won't know until it's finished, sealing it into the vault as it streams, and copying or moving files by moving references instead of bytes. A lot of small, fussy correctness that adds up to "it just behaves like a folder."

See what your node is moving

New this week: an operations monitor. It's a live registry of what the node is doing right now — which files are being read, which peers are pulling blocks off you, what's replicating in and out — surfaced in a panel in the web UI. When the mesh is busy you can finally see why, instead of guessing from the disk light.

S3 caught up

The S3-compatible API filled its last conspicuous gaps: server-side CopyObject and UploadPartCopy (including across buckets), a batch delete, and a sweep that reclaims multipart uploads nobody ever came back to finish. The whole point of S3 is to plug real tools — Immich, Nextcloud, a static-site host — straight into a vault, and those tools lean on exactly these verbs; now they stop tripping over the missing ones.

Underneath all of it, a quieter theme: concurrency. Block writes serialize per hash behind a shared keyed mutex, fetches came off the global lock, and quota reservations hold across a whole ingest — the unglamorous groundwork that keeps a busy node correct, not just fast. Still pointed at 0.8.

Since last week

• Vault mounting: mount a vault as a real drive — Windows (WinFsp, fetched on demand), Linux (FUSE), the Android Files app (streamed, not downloaded), and WebDAV — via meshhold mount, a tray Drives section, or "Mount as drive" on the vault card; reads stream block-by-block
• Write-back: mounts accept writes everywhere — drop-in files (chunked, encrypted, replicated), rename, new folders, in-place edits, and saving into a vault from any Android picker; a streaming write API that accepts a file before its length is known and seals it as it lands
• Server-side moves: copy or move a file without moving its bytes; first-class folders (an empty folder is a folder, not a zero-byte file)
• Operations monitor: a live registry of what the node is reading, serving, and replicating right now, with a web panel
• S3 completeness: CopyObject + UploadPartCopy across buckets, batch delete, and a TTL sweep for abandoned multipart uploads
• Networks in the store: the active network lives in the runtime store now, not config.yaml (which becomes a seed); CLI networks connect / disconnect / rm
• Concurrency + installer: per-hash block serialization off the global mutex, quota reserved across an ingest, and an installer that closes the tray and stops the node cleanly before an upgrade