Of course there isn't, but it limits efficiency and features. For example, you will miss all the fancy features Google Images does in cloud and user experience might be slower, since everything must be processed and downloaded on client side. Some level of metadata is always unencrypted.

It is very complicated to get this right from development standpoint. In true E2E, client must be "fat", kitchen sink and everything. Pretty sure Dropbox isn't like that right now. E2E is not a "feature", it is like a different paradigm of problem solving.

What I'd really like is for the encryption to be plugable and orthogonal to file syncing.

Ie: authentication with dropbox/proton/bittorrent concerns only that you pay your storage/ingest/egress bill, but is otherwise unprotected and in the clear. Encryption of the file payload and metadata as a "bring-your-own" — on device — stream cypher (and key derivation, key management). Key exchange and sharing among devices or users might then use yet another service or mechanism.

Pretty sure presenting all that in a slick easy to understand way has significant challenges, but it would be great to alleviate some of the dropbox as a single point of failure.

Of course not. It’s just storing bits at the end of the day. But storing seemingly random bits will always be more expensive than storing predictable bits, and this case is no exception: Proton is roughly 4x more expensive per bit than Dropbox.

Was the question whether or not it is hypothetically possible to provide an E2EE storage service? Surely you can apply your engineering chops here. Of course it isn’t. But there are trade-offs, as with literally any engineering choice.