I know, that there are two other topics related on this topic, but as the other posts are very old I would like to give a new perspective to this topic.
Storing posts and messages encrypted in the postgres database would be better - not only while it´s more secure, but mostly because you can tell your friends: I can´t see your private messages as podmin. Till now I can see it, when I use my postgres user to inspect the database. It would be more trusty and second it´s better for any gdpr compliance: when I cannot directly access to user generated data I have less gdpr compliance problems.
The trouble with this approach is that it’s only marginally more secure. As a podmin, I can still see your posts, comments, and private messages, it’s just slightly harder now, because I need to decrypt them first with the key that I chose, or I need to muck around in the database a bit more and use the key that you chose. I’m not saying that these provide no additional security; they clearly do. It’s just that nobody has seen it as valuable enough that they want to invest their own time in it.
End-to-end encryption is difficult to do successfully. The NextCloud team has been working on it for some time, and they don’t have to deal with shared or federated content like Diaspora does. Key recovery, client-side decryption, all of this gets to be difficult, and that developer time takes away from other work.
That said, if you’d like to submit a pull request implementing server-side encryption, please do! We’ve no shortage of feature requests, but we have a definite shortage of developer hours, so any you could contribute would make a positive difference for the whole community!
There’s an explanation from one of the core developers why D* doesn’t implement encryption of data on the server in this comment on one of the existing issues you referred to. It seems that the situation hasn’t changed since then, and Brad’s explanation on this discussion gives further detail why it’s not likely to be possible to implement successfully.
A podmin will always have access to your stuff. If nothing else, they can reset your password to one of their choosing, then login as you. They own the server. If they want to put a packet sniffer in place after the TLS decryption but before your data gets to the diaspora process, they can. You are not going to design a system like this where you protect the users’ data from the administrator on a system. Remember: Diaspora is a system where you are putting data that you want to share. This is not Nextcloud or a fileserver where you store data that’s intended to be totally private and shared with no one. This is social media.
Before we say “encrypt everything” we have to ask what that encryption protects against. Who can’t see the data and why not? Remember that the data is shared somewhere. Via the federation it has left your pod anyways (unless you never share outside your own pod). So what are you trying to protect, from whom and how? Encrypting data in the database doesn’t protect against many interesting use cases when you think about social media servers.
Yes, the “old” discussion is still up-to-date, nothing will change when you just discuss the same stuff again (it only uses time that could be used for other things). So please read the old discussion (as linked by @goob) and if you really have something new, add it there as a comment.