Live data from Hacker News

Zulip – Threaded real-time chat for distributed teams

zulip.com

51–60 of 95 posts

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

#51

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.

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.

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

#52
post #45
post #39

Earlier quoted context omitted.

https://zulip.readthedocs.io/en/stable/production/mobile-pus... has some more detail around mobile 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.

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

#53
post #23

Earlier quoted context omitted.

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

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.

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

#54
post #47

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.

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

#55
post #47

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.

Discord added threads this year and it’s lovely.

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

#56

Earlier quoted context omitted.

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.

Plus it's fast, Slack is a vat of molasses and I hate my life every time I have to use it.

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

#57

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…

I wondered why Signal notifications just say "you have a message".

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

#58
Related:

Zulip 5.0: Threaded open-source team chat - https://news.ycombinator.com/item?id=30846659 - March 2022 (86 comments)

Zulip Cloud security vulnerability with reusable invitation links - https://news.ycombinator.com/item?id=30479430 - Feb 2022 (35 comments)

Why Zulip will stand the test of time - https://news.ycombinator.com/item?id=29595926 - Dec 2021 (80 comments)

Zulip 4.0: Threaded open source team chat - https://news.ycombinator.com/item?id=27149123 - May 2021 (170 comments)

Zulip 3.0: Threaded Open Source Team Chat - https://news.ycombinator.com/item?id=23860338 - July 2020 (133 comments)

Zulip 2.0: Open source team chat - https://news.ycombinator.com/item?id=19284321 - March 2019 (96 comments)

Zulip Server 1.9: HipChat import and much more - https://news.ycombinator.com/item?id=18400988 - Nov 2018 (123 comments)

Zulip – Open-source, threading-based Slack alternative - https://news.ycombinator.com/item?id=17622987 - July 2018 (99 comments)

Zulip 1.8: Free software Slack alternative with email-style threading - https://news.ycombinator.com/item?id=16863675 - April 2018 (148 comments)

Zulip Server 1.6 released - https://news.ycombinator.com/item?id=14506426 - June 2017 (14 comments)

Dropbox has open-sourced Zulip - https://news.ycombinator.com/item?id=10279961 - Sept 2015 (313 comments)

Dropbox Acquires Zulip, A Stealthy Workplace Chat Solution Still In Private Beta - https://news.ycombinator.com/item?id=7419408 - March 2014 (14 comments)

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

#59
post #52
post #45

Earlier quoted context omitted.

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

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.

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

#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 work just fine.

Post reply on HN