The number of providers doesn't matter, actually. It could be just one, as long as it is easy to switch whenever you need. See GitHub.
For complex applications you might want a richer API but I think that for now making it easy to adopt is a key feature and I generally just want to stick a serialized state in a small number of "files" anyways.
I really hope this takes off at some point.
There are some half baked GraphQL query engines for it as well as some SQL query prototypes on top, but not quite ready yet. What were you wanting to build?
Oddly enough, I keep going back conceptually to the 'gevulot' concept from Rajaniemi's 'The Quantum Thief' as an idealized implementation of this.
Still, you do raise a good point - that S3 bucket is owned by the app, not the user. But it doesn’t have to be this way forever, and AWS is an Amazon product. Amazon has the credit card information of nearly everyone in the world. I would not be surprised if in the future, we see a sort of federated model, where users of an app pay for their own storage at S3 by linking their Amazon account. The app would be like a reseller/affiliate of Amazon, and could pass storage costs directly onto their users without worrying about complexities like pricing tiers to account for variable customer requirements.
1. I update some data on my desktop.
2. I shut down my desktop.
3. I power on my laptop.
How and when does my laptop get the updates made on the desktop?
(edit1) One idea for a solution is asking peers for help: my data gets encrypted and seeded to many peers, so it is always available somewhere.
(edit2) While I like the "own your data" aspect of this, I dislike the "everything in a browser" aspect. At what point is this easier as just a native program?
Even with a server side DB, they could lie about their results or hack the game to do better.
If that were a part of the conventions, or even if it isn't, services could sign their own versions of data in legal states – as with signed/encrypted cookies. Then out-of-agreement edits could be detected, and possibly rejected as errors, rather than causing other surprises. (This could make for some ugly partial-failure/unexpected-state cases, though.)