Hm. This is a topic I spent a lot of time thinking about. I get the concern, but I always doubt the actual usefulness of such an encryption level for applications that are not p2p. Some random thoughts.

With your first method, storing the private key encrypted in the database, there is an even more drastic downside than the ones you mentioned, unfortunately.

The plain text private key is accessible to prying admins when the user’s session is open.

is actually not your biggest concern at all. The admins have access to the source, and thus also have access to the login form itself. There is absolutely no guarantee that they did not implement a method that logs your clear text password into the database - and the end user has no way of checking that. Or, even worse, the admins could simply use a static encryption key, regardless of the users password. Even if you would do the entire encryption within the browser with some JS, for normal users, they are unable to actually check if the password gets transfered over to the server.

This method might increase the level of confidence for users, as it is talking about a lot of encryption, but the actual improvement is basically non-existent. You'd still have to trust your admin, so nothing changed, really. (Well, it would make stealing data in case of a data breach much harder, but that's another story)

That's one of the reasons why I dislike this approach so much. It lulls the user into a false sense of security. If the admin wants to steal their data, they still can. So really, what would change? You claim we don't really protect our user's data, and up to a point, you are right, but is this approach any better, or is it even worse?

As for the third-party client, which basically turns the server into a zero-knowledge data storage: Well, that would actually somewhat reliable protect the user's data from curious admins. But, let's be honest here, is this a viable solution for us?

We (as in: all distributed networks) are already hugely unfavorable as we have some downsides per-design, like bad global user discovery and the fact that you somewhat need to understand the principles to use our applications. If we ignore all technical aspects and just consider UX, having the user store the encryption key on a client has horrible implications.

There are certain ways of implementing such a thing. One way would be actually store some kind of key file on the device, but that's really, really bad. What happens if the user decides to login on a new device? They'd have to move the key to the new device, which is super bad. What happens if they loose their device for some reason? Most social networking happens on mobile devices these days, and those devices are really prone of getting unavailable for a wide range of reasons.

There are ways to have the keys be exchanged between devices automatically, and there are ways of using a user password to derive a key (if you're interested in that kind of stuff, the technical docs behind Firefox Accounts is somewhat interesting), but ultimately, there is a huge decrease in UX. Which given our goals, is probably bad.

Not going to mention that you still have to trust your client. For us nerds, this may be easy (read the source and compile the client ourselves), but for non-technical end users? I doubt.

Ignoring UX, would a zero-knowledge server even work? There is a lot of things we need to do on the server. Stuff like parsing contents to check for mentions. Send notification emails. Maybe even send push notifications to clients so they don't have to pull. Sooner or later, you will need to have access to the contents on the server to perform some actions, even if it's just to add some more comfort for our users. So far, I have not yet found a solution around that, besides throwing all the logic into the clients. I don't think I have to tell you why that is a bad idea. :)

Ultimately, this issue boils down to a few simple solutions: Is this an issue we actually need to solve for our users? Can we solve this issue without compromising UX in any way? Can we solve this issue in a way that's actually secure, and not just lulling our users into a false sense of security?