product: BYO / community storage providers (plugin pattern for non-default backends)

[zachdunn]

In plain terms

Storage today is hardwired to the hosted product's providers. There is no defined way for a self-hosted workspace to declare "my objects live somewhere else" — no config shape, no provider registration, no docs contract. We need that pattern before community providers can land.

The forcing function is real code: addisonlynch's github-branch provider (from #414) already implements the Adapter interface and is the first concrete candidate. Per the decision on #414, it belongs in self-hosted deployments — the hosted product will not take contents: write on the public App — so the missing piece is entirely this wiring.

Context

• product: private-repo attachment privacy (guessable gh/ keys on public CDN) #414 — decision thread; the provider's constraints (embeds-only, repo weight, retention-by-branch-rotation) are documented there
• VISION.md — BYO-storage direction; this is the general case of the BYO R2 work
• packages/storage — the Adapter interface providers implement

Questions to settle

1. In-tree vs. plugin. Do community providers ship inside packages/storage (present but undocumented for cloud), or as separate packages with a registration mechanism?
2. Config shape. How does a WorkspaceRecord declare a non-default provider, and where do its credentials live? (Plaintext tokens in the workspace record are not acceptable; self-hosters need an env/secret indirection.)
3. Capability contract. Providers differ in what they can do (no presigned uploads, size caps, no server-side copy). How do the API and CLI discover and degrade — hard error vs. feature detection?
4. Support boundary. What do we promise for community providers — CI coverage, review bar, "works with self-hosted only" labeling?

Acceptance criteria

• Written decision on the four questions above
• Config shape documented for self-hosted deployments
• github-branch provider PR unblocked with a clear target shape

Out of scope

• The github-branch provider implementation itself (follows once this settles)
• Any hosted-product exposure of community providers

[addisonlynch]

Just my two cents here…I would keep things as simple as possible for now. files-sdk already ships adapters for most major storage providers (s3, dropbox, etc), so it’ll just be config buildout rather than new adapters when you want to spin them up. Extend when requests for new ones actually come in.

No need for a plugin system or formal support tiers at this stage. Especially with AI now you’ll probably see folks just throw up a PR to add another provider if they’re going to need it.

For now, #641 covers my case (thank you), so no urgency on my PR. I'm happy to rework it to fold in as an adapter should the blueprint be helpful.