Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zulip – Threaded real-time chat for distributed teams

zulip.com

Post reply on HN
Print view View original

61–70 of 95 posts

Re: Zulip – Threaded real-time chat for distributed teams

#61

Post by wnolens »

stavros wrote: post #41
wnolens wrote: post #12

Given the 'tour', it's slack with named threads (that can be pinned). I like that feature. But it seems a pretty small thing. What are the other things that stand out about it? other than being open source.

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.

Re: Zulip – Threaded real-time chat for distributed teams

#62

Post by usr1106 »

tkiolp4 wrote: post #49

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”?

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.

Re: Zulip – Threaded real-time chat for distributed teams

#63

Post by noizejoy »

stavros wrote: post #50
KennyBlanken wrote: post #38

Earlier quoted context omitted.

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: 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…

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 work…

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?

Re: Zulip – Threaded real-time chat for distributed teams

#64

Post by usr1106 »

tkiolp4 wrote: post #49

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?

Re: Zulip – Threaded real-time chat for distributed teams

#65

Post by tabbott »

KennyBlanken wrote: post #38
samatman wrote: post #29

I hope at some point to see a federated implementation of the Zulip communication model over Matrix. https://github.com/zulip/zulip/issues/356 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 acc…

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: 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…

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.

(I lead the Zulip project)

Re: Zulip – Threaded real-time chat for distributed teams

#66

Post by stavros »

wnolens wrote: post #61
stavros wrote: post #41

Earlier quoted context omitted.

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.

Re: Zulip – Threaded real-time chat for distributed teams

#67

Post by stavros »

noizejoy wrote: post #63
stavros wrote: post #50

Earlier quoted context omitted.

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 work…

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 - endin…

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.

Re: Zulip – Threaded real-time chat for distributed teams

#68

Post by letmeinhere »

sdevonoes wrote: post #60

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…

Yeah, I think the key distinctions are:

- 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.

Re: Zulip – Threaded real-time chat for distributed teams

#69

Post by tiffanyh »

samatman wrote: post #29

I hope at some point to see a federated implementation of the Zulip communication model over Matrix. https://github.com/zulip/zulip/issues/356 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 acc…

Two XKCD comics come to mind.

First this one [0], which is the problem and then this one [1] how we solve it.

[0] https://xkcd.com/1810/

[1] https://xkcd.com/927/

Re: Zulip – Threaded real-time chat for distributed teams

#70

Post by bachmeier »

vitro wrote: post #43
bachmeier wrote: post #32

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.

You can set up Alert words in your personal settings and when that word appears in the chat, you will get notified as well.

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.

Post reply on HN