You can always encrypt local data even if the metadata is not encrypted. But that restricts it to the device itself by default, not even your other devices on the same account can read it.
If you want encrypted and shared with other devices or users you have to surface key management to users which is very difficult to do. Signal and a few others do this but they’re very bespoke to the specific business logic. To provide a general purpose abstraction layer is still an open problem, afaik.
I'm not asking for the problem of key derivation to be solved by ElectricSQL per se, just wondering if it can handle E2E encrypted data in any way. That said, I disagree with how difficult it is: there are a lot of approaches that are not too ridiculous. For example, a simple approach to E2EE is to use a PAKE like SRP to do password authentication, then since the password is kept secret, you can use a normal KDF to derive a symmetric key from the password. From here, you can e.g. store symmetric and public key matter on a server or synced across your clients, encrypted using the password/KDF. If this sounds familiar, it's exactly how password managers work and the main downsides are that it requires password authentication (can't use any auth mechanism that doesn't somehow discretely convey a secret to the client) and the forgot password situation is more complicated (if you have no backups of the key, you can't recover any data. However, that's not an unreasonable compromise in exchange for E2EE.)
Just like TLS, it'd probably be bad if most people implemented SRP from scratch. That said, I did write my own implementation of SRP-6a (a variant of SRP based on the RSA cryptosystem) in TypeScript and I found it fairly simple to do. There are also PAKEs that provide even better security properties than SRP-6a, but good implementations of them are still lacking for now.
What Matrix does seems pretty simple, it just has a lot of moving parts and nuance; the underlying keys are essentially sent directly between clients after a key exchange is performed and verified out of band to ensure there is no eavesdropping and that the two clients are connected to who they think they are.
As far as I know, Signal sidesteps key management almost entirely and only allows one logged in device, and everything else must proxy through it. That's pretty lame, though I understand the stakes are very high to get it 'right' and keeping the moving parts to a minimum was likely high priority.
I don’t disagree with your technical assessment per se but I would would not label any of this “pretty simple”, except for special purpose apps with technically competent users.
Academically it’s in a decent state, but tech- and UX wise I’d say it’s immature. It virtually penetrates all layers of a normal stack (including layer 8). For apps it’s at least possible but the web is very tricky as a platform for anything e2ee without absurd usage requirements.
The tech choices that remain after deciding on an e2ee model are severely limited and language dependent, and spans deeply across persistence layers, software updates, authn, authz, social graphs, moderation etc etc. And even so, there are many subtleties in terms of privacy and information leakage that are often necessary compromises for features that many apps take for granted today. Without any social aspects it’s significantly easier (eg PAKE is best suited for for interactive/online two-party operations).
I do agree that the UX of a lot of E2EE software is pretty bad, and if you wanted to make e.g. a chat application, then yeah, it's not necessarily "simple". In practice it can become quite a mess. And honestly, I think a lot of apps have just done a poorer job than what would've been possible without much hassle because it's relatively new territory for a lot of developers.
On the other hand though, we're talking in the context of local-first apps, and the set of constraints imposed by local-first apps already does limit you substantially. If anything, local-first is more complicated in a lot of regards; in my mind, the worst part about E2EE is trying to keep track of all of the different keys you wind up needing to wrangle, whereas with local-first, usually, you're all-but guaranteed to run into CRDTs first-thing, which impose a whole bunch of limitations on the structure of data and the operations you can perform on that data. It is possible to share things in a local-first app, but there are limitations to how much a CRDT-based app can scale for a single document.
And that's why arguably, it's one of the perfect places to add encryption. If you're already talking about apps that deal with small-scale documents and that necessarily do most of the work on the client, you may as well encrypt it. All of the clients are "equal" as far as the data structure goes and the server(s) mainly exist to sync to; it's perfect.
When thinking about the E2EE UX of local-first apps, I think of password managers and not chat applications. I think it's closer to the former than the latter in terms of constraints.
If you want encrypted and shared with other devices or users you have to surface key management to users which is very difficult to do. Signal and a few others do this but they’re very bespoke to the specific business logic. To provide a general purpose abstraction layer is still an open problem, afaik.