PGP encrypt Content_Body-Field (post.post) in Database on Server

[viisauksena]

While all the Metadata could be preserved there is no real reason why the content of each post/message itself shouldnt be encrypted.
decryption could be done in several ways (and so implementation could go in several steps)
0. there is a opt-in in no encryption :-( (maybe true for all public content)

1. decryption is also serverside, this maybe isnt so silly as you think, while the potential key could be stored somewhere else than in the database itself. (maybe diaspora.yml, or even better is sessionconnected actual user password and deleted after logout and could only restored when user login with password)
2. decryption is done on browser by a) getting the password protected key which is encrypted and used in browser for javascript encrytion, or b) by having the key strictly only yourself
   (openpgp.js for roundcube follow this pgp implementatio)
   (maybe this becomes tricky on windows and mobile browsers where is no nice crypto available)

while the messages are copied to the pods itself it should easliy coexist with working pods, even if they dont encrypt itself.
Later on there could be a opt-out for not sharing non-public content to pods which cannot encrypt content.

Eventhough its not ForwardPrivacy somekind of PGP implementation should work fine. (while pushing messages and post actually works really similar to this)

THIS DOES ONLY EFFECT THE CONTENT !
all the metadata is the same, so all the way how Diaspora is working actually stays the same

[jhass]

there is no real reason why the content of each post/message itself shouldnt be encrypted

I strongly disagree, see #5548 (comment).

I'd love to discuss my arguments against it, especially since you yet have to provide arguments for it. But since I strongly disagree and we'll probably have to vote about this in the end, this is not the right place, please open a thread on Loomio.

[viisauksena]

i agree and disagree :
(+ ref: https://github.com/diaspora/old_diaspora_wiki/blob/master/Why-client-side-encryption-is-a-bad-idea.md )

my main part is this, if data is encrypted and send out as it is to the recipient it should be easy to use some sort of javascript (which is already used in the page) for this symmetric decryption at the end, and i guess a mix out of an password protected cryptobobble which is decrypted at the browser in the moment of login and saved in a cookie , as cookies maybe already saved should be fine.
For sure its still easy for the podmin to exploit this, BUT it is only encrypted data at the server, and no law enforcement, or 3rd party malicous podmin of forgotten still connected users can do anything against it.

the encryption in the first place with given public keys associated with pod-addresses should not produce as much overhead.

if i find time, i'm willed to discuss this further on, or ask a friend if we do a fork - and if people are happy - it could be implemented/merged_again, maybe opt-in-experimental