Live data from Hacker News

Zulip 3.0: Threaded Open Source Team Chat

blog.zulip.com

21–30 of 134 posts

Re: Zulip 3.0: Threaded Open Source Team Chat

#21
post #19

Unrelated question - I went to chat.zulip.com in the browser and signed up. Scrolling through the messages (pixel xl2) is incredibly laggy. If I were to build a similar UI on some project, what's a good way to ensure good scrolling performance on the web?

I find the scrolling quite fast. Do you have a huge amount of unread messages by chance? I think I remember some issue where a gigantic amount of unread messages can reduce performance. There's a 'mark all messages as read' button.

Re: Zulip 3.0: Threaded Open Source Team Chat

#22

I am looking for something to replace XMPP with our team; I wonder if Zulip could be the one. I do like the thread idea. Does anyone know if there is a CLI client, and if E2E encryption is possible with Zulip? It does not seem like these are built-in, but maybe someone built these as add-ons somewhere. I love XMPP, and OMEMO, but Profanity, and Conversations have some weird quirks when used together that we would rat…

There is a Zulip CLI client - https://github.com/zulip/zulip-terminal .

Awesome, and it seems to be official as well. They could mention it on their website, even though it is still not considered stable.

Now to look for E2E encryption support.

Re: Zulip 3.0: Threaded Open Source Team Chat

#23
If curious see also (related threads):

2019 https://news.ycombinator.com/item?id=19284321

2018 https://news.ycombinator.com/item?id=18400988

2018 https://news.ycombinator.com/item?id=17622987

2018 https://news.ycombinator.com/item?id=17622707

2018 https://news.ycombinator.com/item?id=16863675

2017 https://news.ycombinator.com/item?id=14506426

2015 https://news.ycombinator.com/item?id=10279961

2014 https://news.ycombinator.com/item?id=7419408

Re: Zulip 3.0: Threaded Open Source Team Chat

#25

Earlier quoted context omitted.

Can't you just make a single "general" room and talk in there? Have you ever used Zulip? Your objection puzzles me a bit because I can't see how it's a problem, since your use case is trivially supported.

Yes, I've used zulip - every single comment spawned a thread or responded to a thread. Users weren't used to responding to a thread, which meant we had threads of single comments constantly . I'm puzzled that you're puzzled. I thought this was the way Zulip worked. It was about 2 years ago, at any rate. Did it change since then? If so, that's exciting in its own right.

This is the case (and it's okay)!

Every message (other than PMs) is within a topic thread which is within a stream.

This can be structured by having ongoing social threads but users do need to know that they should respond to existing "broad topic ongoing" threads instead of creating a new micro-thread for every message.

We structure the Streams into roughly:

- company-wide announcements

- org streams

- team streams

- social

then within #social you could have ongoing topics like "books", "weekend", "music", etc...

You can also restrict stream access as needed (only team members can view the team stream).

Re: Zulip 3.0: Threaded Open Source Team Chat

#26

Earlier quoted context omitted.

Yes, I've used zulip - every single comment spawned a thread or responded to a thread. Users weren't used to responding to a thread, which meant we had threads of single comments constantly . I'm puzzled that you're puzzled. I thought this was the way Zulip worked. It was about 2 years ago, at any rate. Did it change since then? If so, that's exciting in its own right.

Hmm, that sounds like something was going wrong, threads don't just spawn, you have to create them, and a thread with a single comment kind of defeats the purpose. Oh, were you editing the subject every time you commented, maybe? That's not indicated, you only edit the subject when you want to create a new thread. In our use case, threads were relatively infrequent and specific to a topic, e.g. "middle name database…

Somehow we had like 15 users and not one of them managed to make a comment that wasn't a new thread - like I said though, it was like 2 years ago. Either there was a bug, or it was a design decision, or maybe even a misconfiguration on the server - regardless it got a hearty thumbs down by the community and we went on to try matrix. I was hoping for Zulip since it was a way easier install than matrix + riotweb was, especially since we wanted to self host everything. In the end all the bugs we had in riotweb and the phone apps were enough for us to jump for MM, which has its own problems but was most in line with what we wanted.

Anyway, if Zulip isn't thread-first, then I guess it's less a competitor to Teams than I thought. The only way we found to make teams work for us and our very small team is to keep everything in a named joint chat and everyone utterly ignores the channels like the plague. It's always amusing when someone posts something to a channel for the first time in weeks/months and then people start responding thinking it's chat and every. single. response. becomes a new thread, because they didn't respond inside the original thread.

Re: Zulip 3.0: Threaded Open Source Team Chat

#27
post #4

Threads are one major reason I like Zulip over Slack, but speed is another. I usually have two different instances open on my browser with no problems, and one of them has dozens of conversations going on at once. Zulip is also one of the only apps I put on my iPhone, and it's straightforward and unobtrusive. For some reason when I use Slack, the keys feel mushy. I think they're doing so much stuff in the background…

They are the primary reason to use Zulip. In this way, Zulip is more of a Teams competitor than it is a Slack competitor. I, frankly, cannot stand threads. I want a chat room, not a realtime forum. I understand why people would like that, but it still bothers the shit out of me. I work for MS so we have to use Teams, but I'd prefer opt-in to threads vs. threads by default. I fully understand and accept that my way is…

Of course you should use what you like, but I'm also puzzled because you can "ignore" threads if you want in Zulip by keeping your focus on the channel.

For example I have a channel called #oil-discuss. It has a bunch of separate threads. If I put the focus on the left bar in #oil-discuss, then it shows me all the messages in chronological order, regardless of thread.

If you click on a thread, then you see only the messages in that thread. So I think it's the best of both worlds.

----

Unfortunately it doesn't go the other way around in my experience -- Slack can't emulate Zulip. I joined Slack to discuss a nascent Python project.

https://twitter.com/teoliphant/status/1217611221396082695?la...

The creator of the channel encouraged everyone to use Slack threads to keep the conversation organized. But the threading was so awkward -- it felt felt like my replies were getting "lost" on the side, outside the main flow.

Multiple people disliked the Slack threading and eventually we tried python-dev's nascent Zulip instance instead. Although I think the conversation died out in both places for other reasons.

Post reply on HN