Something I didn't see before, is that a bunch of open source communities seems to starting to use Zulip now as well. I've only seen it in a "remote software company" context before.
Here are some case studies from Zulip themselves about specific organizations, how they moved to Zulip and how they are using it:
Zulip has long been popular with open source projects (https://zulip.com/for/open-source/), as well as a bunch of other non-business use cases (teaching, research, conferences, etc.). One reason folks might feel like it's new is that we recently reworked the Zulip website to discuss these other use cases for which Zulip is popular.
We have always had a practice of prioritizing feedback and feature requests from open source communities, because improving the productivity of the global open source community is an important part of our mission as an organization.
One of the largest such investments has been the native public access option (no account required!) that we released earlier this month:
Please for the love of his noodliness, stop passing notifications in plaintext to push messaging providers. This five year old ticket is embarrassing: https://github.com/zulip/zulip/issues/6954
I hadn't realized this before this thread, but the nice thing about using corporate-sponsored OSS is that I can put a developer to work submitting a PR to my tools if I care strongly enough about the missing feature.
It does take a bit of getting used to. Zulip is kind of a cross between chat and a forum.
However, once I did get used to it I think it's been great. Organizing chat into defined topics is super useful for following discussions you're interested in, filtering out those you aren't and for keeping conversations going across time zones.
It's more discoverable than chat but not as rigid as an actual forum. I feel it works well once the learning curve has been surmounted.
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.
I nearly posted 1810 myself. As for 927, I hope Randall gets around to the other side of the picture someday, because I remember Novell, Token-Ring, Banyan Vine, Fido, and around a dozen more ways of shlepping data around, which have been utterly eclipsed by IP and Ethernet.
Matrix is good enough to capture the network effects and provide the consolidation pressure the field badly needs.
Federation would make me almost instantly recommend it for a handful of cases, but in the meantime they have a lot of catching up to do in the privacy department.
Behold, the two five year old tickets requesting that they stop passing notification text to Apple/Google cloud messaging:
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."
Howdy and thanks for sharing that these issues are important to you!
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.
This is extremely disingenuous. There are tons of usability issues when you have E2EE, to the point where you'd basically have to redesign Zulip and it wouldn't work the same way (e.g. how do you add a colleague to a chat channel and have them see old messages that they don't have keys for?).
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.
Since you’ve been in the field, and have thought about it a lot more than me: isn’t privacy inversely proportional to the size of group who’s in on the secret? And that’s not even a technology issue.
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?
That makes sense in people terms, but in cryptography terms you treat some people as trusted, and some as untrusted. The goal of E2EE is to keep the two groups entirely separate.
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.
If I want my messages to stay away from the public Internet, why would I even want to receive message content over unencrypted email? That makes no sense. Receiving notifications while I am not even logged in also makes little sense because I obviously did not consent to them. And having optional E2EE lets you choose which kinds of messages you don't mind leaking.
It is deeply unfortunate that a business model stands between open source software and serving the urgent needs of its users. A chat platform should provide E2EE as a matter of course.
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.
It did require a lot of effort for Element, Element is a competitor to Zulip, and I found the UX around E2EE of Element to be perfectly acceptable and consistent with UX of the previous versions, so your comment was also a bit disingenuous IMO.
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.
Woah there at least let's acknowledge that e2ee is a BIG ask and would concretely hurt usability. A secure e2e messenger should pass the "mud puddle test" [0] meaning if you drop your devices in a mud puddle and then slip in said puddle and crack yourself on the head, you should be locked out of all your accounts.
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.
[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.
That's a setting you can configure. You can also choose whether it shows the sender's name.
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.
One thing that I don't see mentioned that is a huge deal that you don't realize at first. The topic for a message can be changed after the fact and by anyone. So you are having a big discussion and at some point it veers off into some interesting tangent (or pointless flamewar). The original person didn't know it that idea was unique and had interest, but afterwards a big chunk of topic_A was actually about topic_B. So later a helpful person will go back and change the topic of the message that started it and all the replies will also move to that new topic name.
This means that someone in another time zone or who was busy during the original conversation can come back later and see the ideas discussed and focus on just one ones that are interesting without having to read huge discussion threads. And the threads can be on-topic because people can prune it after-the-fact.
Yes, this does mean you need to be a "team" and trust each other to make reasonable edits to the chat history. Just like a wiki, it sounds like a crazy idea, but works great in practice.
Reminds me of thread moderation in forums - merging threads and such to keep similar topics together when they spilled over. I really liked the carousel demo and how they tried to differentiate, would be a good challenge to explain what you wrote in a single panel.
The carousel on the main page is very easily understandable, which is great!
The whole topics (sub-channels, basically) idea seems interesting as well, though personally the solution itself seems pretty similar to two other great pieces of software out there:
- Rocket.Chat https://rocket.chat/ (the Jitsi integration was especially nice)
- Mattermost https://mattermost.com/ (really simple to setup)
Both of those also seemed serviceable, decently familiar and usable. I guess even Nextcloud Talk could work if that suits your environment better https://nextcloud.com/talk/ though personally it felt a little more barebones in comparison.
Has anyone extensively used any of them and can share what details/differences jumped out at them? Admittedly, i probably missed most of those myself and just saw them as similar, self-hostable chat solutions.
I haven't used Rocket.Chat, but I've used the other two:
Threading feels bolted on in Mattermost, but is the primary feature of zulip.
Think of Zulip as a realtime version of NNTP, and Mattermost as a more modern IRC with a "reply" feature. The "right" way to use Zulip and Mattermost is quite different, though each one can be easily used as an inferior version of the other.
We of course use our own product every day and when I first joined the company in 2019 I also found that threading felt "bolted on". Primarily because channels rendered everything in the same linear feed regardless if it was a message or comment so there wasn't much point in taking the time to first hit reply.
However, Collapsed Reply Thread [0] has been a game changer for me and not only do I no longer feel that way about threading, my productivity would plunge without it. That feature has been in public beta since last summer [1] and will go into general availability in two weeks to officially become the "right" way to use Mattermost. Not to say that it's the same as Zulip, just sharing an updated perspective.
I've tried moving my teams to mattermost now twice and always we ran into the issue that integration for live meetings was painful. Neither zoom nor Google meets was possible to set up in an easy to use manner so everybody could jump on a call when needed
That suck and I'm sorry to hear that. We're releasing public beta for built-in calling functionality on June 15 for both cloud and self-hosted offerings, you could give it a try to see if it meets your needs.
Maybe I'm missing the point, but based on their example, what would be the difference between the Slack channel #annual-summit-tuesday-night-catering and the Zulip topic #annual-summit - tuesday night catering?
I get the point of having topics (less people involved. Kinda like subreddits)... but in Slack I create channels targeted for very specific topics (like the #annual-summit-tuesday-night-catering one) and they work just fine.
- the "topics" are grouped under "streams" that are defined at the organization level. Slack lets every individual set up star groups for channels, but in practice channels are an unorganized mess for all. And, because they have that container, topics are just zero-friction to define.
- Streams, not topics, have membership and permissions. I like this because it means that streams can be defined as an _audience_ for a number of topics. Whether that topic is relevant to you at the moment is a different question, but I often want to be able to skim all of my (e.g.) `team-galactus` topics quickly before moving on to stuff about `greater-denver` or whatever. I also don't want to have to invite people to (or exhaustively document) all of the various topics that they might have a connection to.
Streams are opt-in. Topics are transient and fast to create, and everyone in the stream will automatically see the new topic. You also get per-topic read position tracking, and stream members can mute individual topics if they want. You can also view the entire stream at once (or even all streams!) with the topics interleaved. The sidebar shows the most recent topics in each stream, so inactive topics are eventually hidden from the main UI (though you can still dig them up if you go looking for them).
Big fan of Zulip. Only problem is that you don't get email notifications unless you're directly @ mentioned in a response, even if you're participating in a discussion, and even if they're replying directly to you. Otherwise I find the threading approach to be a big win.
Thanks for the feedback! We're planning to extend our notifications system model to let you specify a configurable policy for which topics one wants notifications for.
In particular, a lot of preparatory refactoring towards supporting this has been merged over the last year, and we have a contributor planning to focus on this project over the summer.
https://github.com/zulip/zulip/issues/12309 is probably the right issue to follow for now. My plan for today included writing a much more technical version of that issue with a specific implementation plan, before someone submitted Zulip to Hacker News :).
When I was building MoonlightWork.com, we had ~3x the DAUs on Email that we did on our website. So, I strongly believe that good email summaries are key to async comms.
I'm working on a similar threaded messages project called Booklet (https://booklet.community), and I think good email summaries are the key to the product. It's hard to do, but there are some cool data opportunities to improve relevancy.
I haven't had much luck with that. Here's an example of where you run into problems:
"You can do that by changing your code like this: [code] Let me know when you have the results."
"Okay, but I'm going to be busy for the next few days. Will post here when it's done."
{Three days later}: "Your suggestion worked! Let me know how to proceed from here."
You can either keep Zulip open all the time - which makes me cringe - or you can go without any form of notification. Then a week later you decide to check back and see the message, but they forgot to @ you.
It boggles my mind why not more of these Slack clones implement threaded conversations. It’s such a popular feature and not hard to implement. It could be introduced in a backwards compatible way in order to not break existing clients.
Which Slack clones are you talking about? This comment seems off-topic here, given that threaded conversations are the ONLY thing Zulip implements (way before Slack), making Slack a bad Zulip clone.
I really like discord's spin on then where threads are actually visible for some limited time. You don't have to hunt for the right message in the channel like in Slack - if a thread was started in the last few days, it's on the list.
As someone who has used Zulip for years, I consider the named threads to be the reason to use Zulip. When used properly, it makes following discussions actually possible without being drowned by other concurrent messages. I'd say Discord is superior in many other ways, but for me this one killer feature still makes me prefer Zulip for work.
Strongly agree. My small, fully remote startup uses it, and this is the big reason we switched away from slack. The name threads are simply terrific for making it a better way to manage communication.
It's not a small thing, it's a huge thing. The way the entire UI is structured around this one difference is great, and makes for a completely different (and much, much better) experience.
Cool. I guess I was wondering if it's so good, slack could build it in a single 2 week sprint (or a third party could just build a slack app/plugin). Creating a near-clone of a well-funded product to tweak one thing is existentially risky, but it sounds like Zulip has actually been around quite a while.
No, for Slack to be as good as Zulip it'd have to basically be rewritten from scratch. Just the speed of the UI means a complete rewrite of the frontend, and Zulip's UX is its strong suit.
The thread-first model is quite different from the free-for-all channel model in IRC/Slack. Imagine the chaos in your email inbox if messages didn't have subject lines or threads. Zulip makes it actually feasible to follow a chat conversation asynchronously, and it's much easier to manage how many notifications you get.
What happened to Gale? That was the other IM system I saw that felt like it had the complexity and internal self-consistency of Zephyr and it feels like it just kind of fell of the face of the earth.
I don't think I've heard of Gale, nor can I find it now that you mention the name... Which I guess is consistent with your "fell off the face of the Earth" theory. If you or anyone else can find a link, I'd love to read about it :).
I used Gale for years (met my spouse there a long time ago!) -- I think you can think of it as a Zephyr clone (as the name implies.. but from Caltech), so it shares the same kind of auto-created sub-categories model, and has federation. There were a decent array of text, nurses, and GUI (Tk!) clients.
All of our supported providers support screensharing. Our philosophy on this is that having a nice integration with multiple dedicated video call providers is almost certainly going to be a better user experience than building our own video call stack.
What’s the difference between a Zulip topic and a Slack channel? Certainly, having one big #engineering Slack channel is unproductive (hundreds of people interacting)… but who’s stopping you from creating #engineering-utc-9 for the people who require it? Put it in another way, what prevents us from using Zulip topics the “wrong way”?
We use zulip at work (yes, heavy geek influence:) ).
Nothing except social pressure prevents people from misusing topics. It happens to all of us, when a different thread gets spawned during a discussion. Sometimes when someone does not know where a question or bug would belong to. But you can move the messages in question to a suitable topic (existing or new) at any time. That used to be a bit buggy in the past, but has been working smoothly for a couple of releases.
Within the same zulip stream everyone can do it (in theory causing edit wars, but it has never happened in our company). To move it to a different stream, you need to be admin. That's sometimes a bit weird, but our admin is quick to do it when discussions went offtopic.
Edit: I can't answer why it was worse in Slack. Luckily I haven't had to use Slack for 4 years. I only remember that it was much worse. Wasn't it so in Slack the user replying explicitly needed to select a threaded reply (and few did so). And even if they had done so, the one coming to work 8 or 24 hours later needed to look through everything (or nothing) because the (possibly threaded) messages had no topic?
What would be the purpose of #engineering-utc-9? Normally disussions go around some topic and those who are interested or have a contribution don't necessarily work in the same time zone.
Yor suggestion would only be relevant if a problem needs to solved now or never. Or for a completely useless chitchat channel that people follow only realtime but nobody would ever read and reply to afterwards.
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.
Obviously subjective but since comments mention UI: I love the web/desktop UI. It's got great power user features including well designed keyboard shortcuts. https://zulip.com/help/keyboard-shortcuts for details (my favorite is "n" for "next topic", which I use every morning to catch up on conversations).
n for next topic, j and k to move up and down within a topic, + to add a thumbs up to the current post, : to add any other emoji, and t to get a list of Recent topics so you can decide which ones to catch up on first. All these make Zulip so pleasant and breezy to use.
I loved most of it, but (1) the search feature, specially for non English language, rely on postgres tokenized search which is worse than slack. (2) there is no "gallery view" for all files shared with a group or a person. (3) The mobile app had different render from the web.. and bad RTL render (4) slack bots compatibility sometimes miss the mark..
Other than that... It worked fine. I kinda liked it but slack is more robust for me (even if slow).
First time I used it, it was a bit confusing, as I didn't really know what to expect. Is it email? Live chat? A forum?
Turns out, it's a bit of both, and trying to use it as any single one of them, will probably make it harder to use.
Basically, I treat it as a live chat where it's easier to participate in different topics at the same time, Slack on steroids where everything is a "Thread" basically.
Sounds similar to Flowdock model? I greatly preferred that and was so disappointed when Slack finally rolled out their version of threading. It felt almost useless in comparison.
Alas, Flowdock is dead now and I've learned to embrace Slack as the better remaining alternative over Teams or Google Chat.
I think it's better than slacks sidebar threaded reply.
It also has better code blocks, less irritating pop up magic and no bots nagging you to fill in credentials all the time.
Here are some case studies from Zulip themselves about specific organizations, how they moved to Zulip and how they are using it:
- https://zulip.com/case-studies/rust/
- https://zulip.com/case-studies/asciidoctor/
- https://zulip.com/case-studies/lean/
I know a bunch of the Rust people hang around on HN, maybe they can fill out any details or tell more about how it's going so far with using Zulip :)