Storing things encrypted on the server is only useful if you can separate data storage from data retrieval/decryption physically and logically.
If the party who runs a theoretical zero-knowledge storage is the same party that provides you with the client to retrieve and decrypt the data, the whole encryption is worthless since a rouge podmin could simply serve you a client that sends them a copy of your decryption key. Since diaspora* is first and foremost a browser-based application, your pod is pretty much always the one also serving you the UI. A theoretical exception exists where a client may exist that only consumes the API, but that’s not valid at the moment because the API isn’t even yet in the stable release.
Implementing server-side encryption would allow us to use a lot of fancy marketing buzzwords and create a lot of perceived security, but there wouldn’t be any actual gain, so we’d rather not.
Even ignoring these technical facts, having a zero-knowledge server makes some of the current features impossible. The server absolutely needs to know a post’s contents to generate embeds, send out mention notifications, make tag-filtered streams work, queue content-fetches for unknown contents linked via a diaspora://-link, and so much more.
And that’s still talking about technical things, I won’t even go into the nightmare that is UX, with forcing users to manually keep track of their decryption key, or telling them that their entire posting history and all content ever received is gone because they accidentally dropped their phone.
Storing contents encrypted is a request as old as the project itself, but it’s unlikely to ever happen. See also the following reply, and that thread as a whole:
Don’t worry, we’re used to this. 