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

71–80 of 95 posts

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

#71

Post by tabbott »

stavros wrote: post #59
tabbott wrote: post #52

Earlier quoted context omitted.

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

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

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

#72

Post by throwaway92394 »

e40 wrote: post #57
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…

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

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.

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

#73

Post by tabbott »

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.

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

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

#74

Post by 0des »

tabbott wrote: post #65
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…

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…

This response says everything I need to know, thanks.

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

#75

Post by 0des »

stavros wrote: post #53
KennyBlanken wrote: post #40

Earlier quoted context omitted.

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.

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

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

#76

Post by samatman »

tiffanyh wrote: post #69
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/

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.

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

#77

Post by tabbott »

tasubotadas wrote: post #46

How are the video call options on Zulip? Is it possible to easily jump on a call with somebody and share your screen?

Zulip doesn't do video calls itself, but we have handy "Start a call" button and you can configure which video call provider that uses. See:

https://zulip.com/help/start-a-call

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.

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

#78

Post by skjoldr »

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…

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

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

#79

Post by tabbott »

yonixw wrote: post #20
brink wrote: post #4

Earlier quoted context omitted.

I've never used it. What's wrong with it?

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

On the search front, have you tried the PGroonga search backend?

https://zulip.readthedocs.io/en/latest/subsystems/full-text-...

(It's only available when self-hosting at present.)

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

#80

Post by skjoldr »

stavros wrote: post #67
noizejoy wrote: post #63

Earlier quoted context omitted.

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

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