pod mirror service for private pods

One of the criticisms early on in the diaspora project has been the requirement that, when users want to share a post or send a direct message to the other user, they must trust: 1) the pod they have an account with, and 2) their friend's pod. That's because either party potentially has a copy of this private data in clear text. The solution of course is end-to-end encryption. That is, user A encrypts their private message before sending the delivery request to their pod, with the encrypted payload. User A's pod passes on the encrypted message (which it can't decrypt) to user B's pod, who delivers it to user B on request. User B then decrypts user A's message on their local machine (via a client application, not the web app). Neither user A's pod nor user B's pod can read the clear text of the private message. A physical world analogy would be if I put a message in a lock box and mailed it to someone who had a key for the box. Maybe the postal service can hold the box until its recipient has time to pick it up, but it can't open it. Only the recipient can.

The basic problem with this approach is that direct end-to-end encryption is impossible to achieve in a web app hosted on a server you don't own fully. There will always be an opportunity for either pod to fake it, and gain access to your private key. So, this feature should ONLY be supported in the client API and not through the web app.

Yes, this is impossible to do in an easy, portable and enjoyable way. If you really need that private communication maybe just use Diaspora to exchange your mail addresses and run PGP over that.

My compromise feature to that would be profile field for your public PGP key, maybe even support for key generation. That way people can easily get each others keys. The downside of this is that it exposes all mail addresses associated with the key, that would have to be made clear before filling that field.

Yeah, I should maybe have clarified. You are correct: since this would be a pure client side approach, there is nothing stopping client applications from implementing this on top of an existing API. However, making the base implementation has its advantages - one it allows encrypted messages to have some form of standard metadata that lets clients, including the web app, to know when a message is encrypted, and then display a nice UI for that, as opposed to just displaying garbage data. Second, it could help facilitate handshakes to an extent, such as hosting public keys or links to them. Finally, the reference pod itself could have this feature enabled and implemented server side - so for instance a private pod could enable it, so that the owner can view end-to-end encrypted messages in both the web app and in client applications.