Bring your own bucket, bring your own model
Storage and the model are each a setting a household fills in with its own provider, and each now has a screen on all three clients. A household that never opens either one hears nothing more about it.
Storage
Any S3-compatible bucket, and a credential nothing can read back
R2, S3, B2 or MinIO. The secret access key is sealed under a key that lives in the host’s environment and never in the database, with the household’s own identifier mixed into the encryption. A ciphertext lifted out of one household’s row and written into another’s fails to decrypt rather than quietly working. No database constraint can express that; only the cipher can.
The key has no read path. It is in no response the API produces. It reaches no tool, because configuring storage is a settings capability with nothing behind it — which is what keeps an endpoint, a bucket name and a credential out of the model’s reach. One file owns both statements that name the column, and the build fails if any other file names it.
A configuration is inert until a real round trip succeeds: write an object, read it back, remove it, and only then mark it verified. A wrong key fails on the settings screen where a person can fix it, never later inside something Bobby was in the middle of doing.
A presigned URL is itself a credential — the signature in it is the key — so it redacts itself when printed, and the table that records every one issued has no column a URL could go into. Logging one would log the credential.
The model
Same shape, and no fallback
An endpoint, a name, a sealed key, and a real request that proves it. The default is Bobby’s own model, and a household that never opens the screen never hears about this again.
A household’s own model failing does not fall back to ours. A sealed key that cannot be opened returns the household’s own choice with nothing to ask, rather than degrading to a model they did not pick. That degradation is precisely the thing the design forbids, and the screen says so out loud rather than hiding it.
The screens
Three states, kept apart
Nothing configured, stored but not verified, and verified are three different facts and the screens keep them distinct. Verification is a real request with a real answer, and collapsing the middle state would claim something nobody checked.
A sealed key is never shown. Not in a field, not masked, not on request. The screen says a key is stored and offers to replace it.
Not built
Managed storage and managed models are not built. They are written down as the paid side of this — the same product with the bucket and the model supplied by us, priced above cost, with tiers that differ by service level and never by removing safety. No tier table exists, because one written before the first paying household is a guess that becomes a commitment.
What is decided is the framing. Bring your own stays the default and the shipped shape, so what a paid tier would buy is not having to choose a provider, paste a key and pay a second bill. Convenience, not privacy.
Where it runs
- Server
- Bucket 9 September, model 10 September
- iPhone, Android, desktop
- Yes, 10 September
- Managed storage, managed models
- Nothing built