[0xbadcafebee]

I'm sure you can come up with abstractions, but without first doing a whole system design (FRs & NFRs, mapping dependencies, customer requirements, etc) you'll have to scrap those abstractions when they don't match up with how the system ends up needing to operate. So I would recommend not even thinking about technical abstractions until you have a very large multi-layered system visualization.

For example: what is storage? A router stores packets temporarily; is that storage? A DNS resolver caches records; is that storage? A browser stores cookies; is that storage? A chat or email server & client may both store messages in different states for different purposes. What storage should be shared and shouldn't be, in what specific circumstances? Who is allowed to read and write to which thing at which time in which circumstance? All of that will affect your abstraction.

[digikata]

These are fair suggestions for the low level detail of my comment. I think the core functionality is providing a web friendly storage access api providing for user control and syncing between multiple nodes. It's been done before but not recently with more recent and lighter protocols. Apps like the classic sample todo or note taking apps frequently shown on HN should really just be able to connect to a user owned storage - get authorized for a stoage allocation either fronting local storage or easy to spin up a node on a cloud hosted vm.

It's sort of a shame that so much of the new web3 storage work intrinsically links storage to a blockchain, instead providing a blockchain integration as one of many authentication/provisioning models.

[0xbadcafebee]

> Apps like the classic sample todo or note taking apps frequently shown on HN should really just be able to connect to a user owned storage - get authorized for a stoage allocation either fronting local storage or easy to spin up a node on a cloud hosted vm.

Let's think of the simplest possible implementation of that.

A todo app wants to write to 'your storage'. What are your options for storage? If it's some thing like Google Drive, that is a proprietary interface, so right off the bat, you are now implementing vendor-specific things, so an abstraction is not worth much. You could make some kind of "JavaScript Framework For Storage", aka a js library that has 50 different proprietary implementations, but that would only work for javascript apps. Which, if you only code in JavaScript, is fine, but if you want to support some other application written in another language, now somebody has to maintain those 50 different proprietary implementations in another language too. That's just not sustainable.

If instead you want to create one standard web API to access storage through, even if you could define exactly what it should do, you now need to get Google to implement that one standard web API. But why would they? They already have their own Google Drive API which works perfectly well for their own purposes. You would have to show them some significant business advantage to throwing away all the money and code they've sunk into their own API (not to mention that all their customers and their apps have sunk into it) and build and adopt this new API. (That assumes you could even get them to agree to whatever standard API you created, as they may want a half dozen extra features that have nothing to do with storage)

By modeling the whole system, you can quickly see all the weird quirky problems that you will run into trying to make this API and get it adopted. It's not impossible, but it's a much larger problem space than you imagine at first.