Comment by jchw

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.