03 — Developer Features

Make BitVault something developers build on. The S3 API and FUSE mount are the two highest-leverage moves; both reuse the storage subsystem and meet developers where they already are.

D1 — S3-Compatible API ⭐ flagship

Full treatment in 01 §5. In short: SigV4 + bucket/object/multipart mapped onto the storage layer → every S3 tool (aws-cli, boto3, rclone, Terraform, Spark) works unchanged, governed by the policy engine. Complexity M · Resume High · the top adoption lever.

D2 — FUSE Virtual Filesystem ⭐ near-flagship

Mount a BitVault space as a local drive with on-demand hydration: files appear instantly as placeholders; bytes are fetched (and cached) only when read.

flowchart LR
    classDef o fill:#dbeafe,stroke:#1e40af,color:#111827;
    classDef f fill:#fde68a,stroke:#b45309,color:#111827;
    classDef s fill:#bbf7d0,stroke:#15803d,color:#111827;
    app["any app (open/read/write)"]:::o --> fuse["FUSE mount (placeholders)"]:::f
    fuse -->|"read → hydrate"| chunks["fetch missing chunks (storage/06)"]:::s
    fuse -->|"write → stage + commit"| sync["sync engine commit (sync/05)"]:::s
    fuse --> cache["local chunk cache (sync/03)"]:::s

Reuses the sync engine (commit protocol, chunk cache, conflict handling, sync/) and storage (range reads, storage/06). On-demand hydration = Dropbox “Files On-Demand” / rclone mount, which prove feasibility.


Why it matters	“Your whole vault as a drive without filling the disk” is a delightful, sticky UX and a serious systems feat.
Complexity	L — FUSE semantics (open/read/write/rename/truncate), placeholder/hydration state, write-back through sync, cross-OS quirks (macFUSE/WinFSP).
Dependencies	Sync engine (sync/), storage range reads (storage/06).
Resume impact	Very high. Filesystem-level engineering (FUSE) + on-demand hydration is rare and impressive.

D3 — SDKs, Terraform provider, first-class CLI

Generated, typed SDKs (Go/TS/Python) from the protobuf contract (ADR-0003), a Terraform/OpenTofu provider (manage spaces/shares/policies as code), and a CLI that dogfoods the public API (ADR-0015).


Why it matters	Lowers integration friction; the Terraform provider makes BitVault part of customers’ IaC — sticky and on-brand for a platform.
Complexity	S–M — SDKs are largely generated; the Terraform provider (CRUD + state) is the meatier piece.
Dependencies	Proto/codegen (ADR-0003), stable public API (ADR-0015).
Resume impact	Medium. A Terraform provider is a nice, recognizable artifact; SDKs less so.

D4 — BitVault as a Backend (BaaS)

Position the API as a storage backend for other apps: scoped API tokens, direct-to-storage presigned uploads (ADR-0011), per-app spaces, usage metering — “Supabase/Firebase Storage, self-hostable.”


Why it matters	Expands the market from “end users” to “developers building products” — a multiplier on adoption.
Complexity	M — mostly packaging existing capabilities (tokens, presign, metering) into a coherent developer product + quotas.
Dependencies	Auth/tokens (ADR-0010), presign (ADR-0011), metering (04 billing context).
Resume impact	Medium. Product/platform framing more than novel engineering.

D5 — Webhooks & Functions (developer-facing)

The event/automation surface as a developer feature: subscribe to events (08), or run code on them (Functions §2). Covered in 06/08.

Priorities within developer

D1 (S3 API) first — highest adoption-per-effort. D2 (FUSE) for the systems wow. D3 is cheap polish. D4 is positioning that the rest enables.