It's very easy to self-host. The only real gotcha are mobile notifications, because those are sent through centralized servers not hosted by you (because of how mobile APIs work).
You have to choose server-wide between sending none (very private), sending redacted notifications (somewhat private, somewhat useful) or sending the full message in the notification (they see all your messages, but very convenient). Or I guess you can modify the mobile client and set up your own push notifications.
Our plan is to add end-to-end encryption for mobile push notifications, and we've got a design, but limited progress on implementation. One can follow the issue here: https://github.com/zulip/zulip/issues/6954.
The clients already use some secret for authenticating to the server, no? Can you not use the same secret for encryption? Or are you using tokens that need refreshing?
The issue here is more complicated. A self-hosted Zulip server needs to send a push notification that reaches the Zulip mobile app on someone's device.
For security model reasons, those push notifications need to be sent to Google/Apple via a server operating by Zulip itself. So your local Zulip server needs to share a secret with the Zulip mobile app on your device, and then it can encrypt the push notification's content so that only the destination mobile app can read it (and the intermediaries cannot).
It's a basic cryptography problem at a high level, but there's subtle details around what metadata can be safely encrypted (the client does need to know which Zulip server's secret key to use!), backwards-compatibility, library choice, etc., that make it not trivial, which is why we haven't managed to implement this yet.
Hmm, I'm not sure I understand. Your first two paragraphs agree with what I said, but, in the third one, why does the client need to know the server's secret key? The communication happens the other way (server to client), no?
Plus, the server already has a shared secret with the client (presumably), the API key. Backwards compatibility might be an issue, if you aren't storing the client version on the server, but that seems like a simple fix.
Can you explain a bit more what I'm missing here? I'm a bit confused.
Correct, it's server-to-client. The model I described above is a symmetric key cryptography design. A model where the client generates a public/private key pair and gives the server its public key when registering for mobile push notifications is also an option.
I agree it's possible in theory to reuse the API key for end-to-end encryption, but I don't think that's the right design. This is in part because the encryption algorithm may, now or in the future, have different requirements for format, key size, etc. But more importantly, a cryptographic weakness in the encryption algorithm should not allow an attacker to stealing API keys.
It might be best to move this conversation to #backend in chat.zulip.org :).
If anyone wants to help, I'd love links to privacy pages that folks really like and/or lists of questions that readers would like to see such a page clearly answer.
