Live data from Hacker News

Zulip – Threaded real-time chat for distributed teams

zulip.com

81–90 of 95 posts

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

#81
post #78
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…

Wait a second, Element has had working optional private and group E2EE for a while, why can't Zulip?

The simple answer is that that's like asking "boats can float, why can't cars?".

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

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

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.

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

#83
post #50

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…

[deleted]

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

#84
post #81
post #78

Earlier quoted context omitted.

Wait a second, Element has had working optional private and group E2EE for a while, why can't Zulip?

The simple answer is that that's like asking "boats can float, why can't cars?".

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.

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

#85
post #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.

Matrix

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

#86
post #50

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…

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.

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

#87
post #85
post #54

Earlier quoted context omitted.

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.

Matrix

Matrix has threads.

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

#88
post #65

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…

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

Stealing this moment -- love and appreciate the tireless work Tim. Zulip's a truly amazing piece of software.

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

#89
post #75
post #53

Earlier quoted context omitted.

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.

Hello Stavros it appears we meet again. How much would you pay a developer to accomplish this task?

I have no idea, it depends on how long it would take, I guess.

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

#90

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…

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).
Post reply on HN