Imagine if you could only use S3 (with atomic guarantees) to store the user’s data?
Latencies are unpredictable as the storage can be running on a raspberry pi on the user’s DSL. Since it’s a blob store, getting the right data might require pulling whole chunks and is pretty slow. There are no indices so queries might be pulling the whole data store. At the same time, I suspect that users want a good quality of service when using the app.
Now that this is clearer, the natural conclusion for an app developer is to keep all the data locally. Have their own internal database with indices and predictable latencies. And then use remoteStorage as a backup/restore solution only.
Huh, I was just this morning thinking how this would be a great idea. It would be cool to add Dropbox as a backend!
Blockstack (now Hiro and Stacks) had something like this in its gaia project. The user had an authenticator app — a desktop app in the Blockstack ecosystem was all I ever used — and that authenticator also provided user-approved storage settings. The system that consumed the A&A API also had a storage API that provided a simple object storage API namespaced to the particular app. Oftentimes, the data for the consumer app never touched the consumer app’s servers: it was all client-side. I think there was a protocol for dealing with data that was too large to fit in the browser’s localStorage, such that the consumer app would cache the data and then transfer it for storage at rest to the user-provided system.
I never really delved into it beyond a few example apps I consumed as a part of interviewing at Blockstack in 2019 but the premise of it was awesome: I, a user, bring my own storage, and that storage can be wherever I want it to be, and I can pay one storage provider bill instead of app devs choosing only one cloud storage system for integration (e.g. and most often Dropbox or GDrive or OneDrive).
How does this differ? I’ll probably read up in the next couple of days…
Wonder how this compares to https://perkeep.org/