Parked by the recovery round (runtime/RECOVERY.md, "Bucket kits are S3-only at this rev"): the bucket kit needs an owner-tier PUT at a NAME the guest derives from the recovery phrase, and only S3 addresses objects by name. Dropbox and Drive resolve ids through a folder walk, so a phrase-derived name is not a location there without a design decision the round declined to improvise. File kits work on every provider (they store no object), so no provider lost recovery coverage.
The likely shape for Drive: a recovery/ folder beside docs/pickup with the derived hex as the FILENAME, resolved through the existing resolve-then-create-or-update machinery (gdrive names are already keyed hex inside known parents — the same trick would carry). Needs: the create/fetch/delete triple parameterized the way recovery.rs's config-parameterized S3 helpers are (the restore fetch runs before engine state exists), and recovery-consume's Drive arm already exists.
Also recorded on the same page: Dropbox recovery-consume refuses by name (its pickup delete has no absence-as-success path; a non-idempotent consume would spin the retry loop) — if Dropbox ever joins the worker's bindable providers, that wants an absence-tolerant delete in providers/dropbox/store first.
Parked by the recovery round (runtime/RECOVERY.md, "Bucket kits are S3-only at this rev"): the bucket kit needs an owner-tier PUT at a NAME the guest derives from the recovery phrase, and only S3 addresses objects by name. Dropbox and Drive resolve ids through a folder walk, so a phrase-derived name is not a location there without a design decision the round declined to improvise. File kits work on every provider (they store no object), so no provider lost recovery coverage.
The likely shape for Drive: a
recovery/folder besidedocs/pickupwith the derived hex as the FILENAME, resolved through the existing resolve-then-create-or-update machinery (gdrive names are already keyed hex inside known parents — the same trick would carry). Needs: the create/fetch/delete triple parameterized the wayrecovery.rs's config-parameterized S3 helpers are (the restore fetch runs before engine state exists), andrecovery-consume's Drive arm already exists.Also recorded on the same page: Dropbox
recovery-consumerefuses by name (its pickup delete has no absence-as-success path; a non-idempotent consume would spin the retry loop) — if Dropbox ever joins the worker's bindable providers, that wants an absence-tolerant delete in providers/dropbox/store first.