I'm at a point of choice fatigue with communication platforms where Zulip being siloed is more important than it being open source. I'm phasing out proprietary platforms in a way that will take years and may never complete. I don't want more apps, I don't want another user account, and I certainly don't want a bunch of user accounts on different servers.
First this one [0], which is the problem and then this one [1] how we solve it.
Matrix is good enough to capture the network effects and provide the consolidation pressure the field badly needs.
Behold, the two five year old tickets requesting that they stop passing notification text to Apple/Google cloud messaging:
https://github.com/zulip/zulip/issues/6954
https://github.com/zulip/zulip-mobile/issues/1190
For those who don't know: if you have an app and want to send a notification to a user, you use Apple or Google push notification services. In both cases, the notification is plaintext but transmitted via encrypted channel to Apple or Google, then transmitted via encrypted channel to the user's phone. But in each case, the push messaging provider gets to see the messaging text.
So companies that give a shit about your privacy send a token instead, that says "hey, wake up, something happened, fetch a notification." Apple likely doesn't do anything with the notification text, but it's a given Google datamines the hell out of it.
They also still don't have any form of e2ee. Here's another five year old ticket requesting end to end encrypted chat, where a bunch of people say "here's a long list of apps that support e2ee" and Zulip devs go "gosh golly how do they handle keys? Math is hard."
I'm going to assume good faith in your comment, but I'm really having a hard time doing it, and I'm one of the people who worked for SilentCircle! Another one of those people currently works for Zulip (hey Austin!).
TL;DR: It would take a ton of effort and would basically require a pivot of the business model. Yet you present it as if it's some afterthought that can be tacked on, completely ignoring the fact that all none of their competitors (Slack, Teams, etc) support E2EE.
And therefore demanding E2EE for groupware might seem almost nonsensical, since wide proliferation of access keys makes the whole secret room subject to increasing likelihood of accidental or malicious compromise - ending up more privacy theatre than actual privacy?
e.g. if there are 1000 different individual keys to access a conversation, how private is that conversation really?
However, this does make sense when you consider your attack model. When thousands of people know a secret, maybe forward secrecy isn't worth the trouble, and you can simply have one master key that people share between them (to prevent the server from reading any of the communications).
There are tons of issues even then, though. For example, you can't send an email notification to someone and show them the content of the message that mentions them (because you don't know it), plus how do you even know they were mentioned? There are probably hundreds of small issues like that, and the fact that the server knows nothing leads you to push most of the functionality to the clients themselves, which leads to more problems.
It is obvious that E2EE would involve a big rework of the codebase, but it is neither impossible nor unnecessary. If there are architectural problems with it, I have to question the original developer intent, as a lot of stuff that E2EE requires to work also improve privacy in general.
I of course have no right to demand work from software developers, regardless of the openness of their code base. It's just, that's really too bad.
There's reasons unrelated to this for why you want to not show the message/sender - namely devices like a desktop you might be screensharing from or if you're concerned about someone seeing it over your shoulder.
I almost leaked a message just taking a screenshot because I didn't notice the notification immediately so I keep it disabled.
The push notifications issue is important to me. I'm the one who opened #6954 five years ago, when we were first implementing mobile push notifications, and I've encouraged contributors to pick it up a number of times over the years. I appreciate your bringing attention to this -- it will likely make it easier for me to get folks excited about working on this mostly invisible improvement. https://news.ycombinator.com/item?id=31573940 elsewhere in today's thread has a bit more technical context for those who are curious.
As a bit of side comment, I think how long ago an issue was opened is not what makes it important. About 250/1650 of our open issues are at least 5 years old, and while some old issues are quite important, many of them are still open precisely because they are not important. So while I agree that #6954 is important, my view is that would still be the case if it had been added to the issue tracker yesterday.
I'll post a separate comment about end-to-end encryption of conversations, since that's a complex topic.
(I lead the Zulip project)
Do you want a Zulip where account recovery is impossible by design? Or where conversation history is unavailable to new users [1]? You might say "well let people opt in if they want e2e" but that's not helpful either. If even 1 user in a group is not opted in then the entire group has the same security level.
[0] https://blog.cryptographyengineering.com/2012/04/05/icloud-w...
[1] This must be the case unless you invent a p2p system for users to bring a new user up to date on the group. And even then people could voluntarily lie about past messages. There are neat ways around all this but the point is that this system is very complicated and doesn't currently exist in practice.