[HN Gopher] Zulip - Threaded real-time chat for distributed teams
___________________________________________________________________
Zulip - Threaded real-time chat for distributed teams
Author : capableweb
Score : 178 points
Date : 2022-05-31 17:26 UTC (5 hours ago)
(HTM) web link (zulip.com)
(TXT) w3m dump (zulip.com)
| tasubotadas wrote:
| How are the video call options on Zulip? Is it possible to easily
| jump on a call with somebody and share your screen?
| tabbott wrote:
| 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.
| jupp0r wrote:
| 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.
| stavros wrote:
| 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.
| jupp0r wrote:
| Matrix
| viccuad wrote:
| Matrix has threads.
| FractalHQ wrote:
| Discord added threads this year and it's lovely.
| viraptor wrote:
| 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.
| [deleted]
| tryauuum wrote:
| What's the current status of RocketChat? How hard is it to get
| push notifications on mobile?
|
| I know I can find answers in google but I want them from someone
| with hands-on experience
| samatman wrote:
| 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 account, and I certainly don't want a
| bunch of user accounts on different servers.
| tiffanyh wrote:
| 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/
| samatman wrote:
| 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.
| KennyBlanken wrote:
| 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 app and want to send a
| notification to a user, you use Apple or Google push
| notification services. In both cases, the notification is
| plaintext but transmitted via encrypted channel to Apple or
| Google, then transmitted via encrypted channel to the user's
| phone. But in each case, the push messaging provider gets to
| see the messaging text.
|
| So companies that give a shit about your privacy send a token
| instead, that says "hey, wake up, something happened, fetch a
| notification." Apple likely doesn't do anything with the
| notification text, but it's a given Google datamines the hell
| out of it.
|
| They also still don't have any form of e2ee. Here's another
| five year old ticket requesting end to end encrypted chat,
| where a bunch of people say "here's a long list of apps that
| support e2ee" and Zulip devs go "gosh golly how do they handle
| keys? Math is hard."
|
| https://github.com/zulip/zulip/issues/6096
| e40 wrote:
| I wondered why Signal notifications just say "you have a
| message".
| throwaway92394 wrote:
| 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.
| stavros wrote:
| 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 worked for SilentCircle_! Another one of those
| people currently works for Zulip (hey Austin!).
|
| TL;DR: It would take a ton of effort and would basically
| require a pivot of the business model. Yet you present it as
| if it's some afterthought that can be tacked on, completely
| ignoring the fact that all none of their competitors (Slack,
| Teams, etc) support E2EE.
| noizejoy wrote:
| 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?
| stavros wrote:
| 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.
| skjoldr wrote:
| 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.
| [deleted]
| skjoldr wrote:
| Wait a second, Element has had working optional private and
| group E2EE for a while, why can't Zulip?
| stavros wrote:
| The simple answer is that that's like asking "boats can
| float, why can't cars?".
| skjoldr wrote:
| 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.
| samatman wrote:
| 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.
| tabbott wrote:
| 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)
| 0des wrote:
| This response says everything I need to know, thanks.
| tkiolp4 wrote:
| 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"?
| usr1106 wrote:
| 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.
| usr1106 wrote:
| 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?
| mherdeg wrote:
| What happened to Gale? That was the other IM system I saw that
| felt like it had the complexity and internal self-consistency of
| Zephyr and it feels like it just kind of fell of the face of the
| earth.
| tabbott wrote:
| Howdy mherdeg!
|
| I don't think I've heard of Gale, nor can I find it now that
| you mention the name... Which I guess is consistent with your
| "fell off the face of the Earth" theory. If you or anyone else
| can find a link, I'd love to read about it :).
| mherdeg wrote:
| Here's a smidgen of context:
|
| https://web.archive.org/web/20020126184926/http://www.gale.o.
| ..
|
| https://web.archive.org/web/20011221165350/http://gale.org/e.
| ..
|
| https://web.archive.org/web/20020214082814/http://gale.org/l.
| ..
|
| https://web.archive.org/web/20011127185333/http://fugu.gale..
| ..
|
| I think it was popular in a Caltech crowd?
|
| I think a zephyrgram was a "puff"?
|
| I think there was a fairly sophisticated tiered location/tag
| hierarchy that is very very broadly related to
| topic/stream/reaction emoji.
|
| Some of the contributor have usernames that look very
| familiar (I think that's the same jtr whose username I've
| seen elsewhere, for example).
| dang wrote:
| 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)
| capableweb wrote:
| Something I didn't see before, is that a bunch of open source
| communities seems to starting to use Zulip now as well. I've only
| seen it in a "remote software company" context before.
|
| Here are some case studies from Zulip themselves about specific
| organizations, how they moved to Zulip and how they are using it:
|
| - https://zulip.com/case-studies/rust/
|
| - https://zulip.com/case-studies/asciidoctor/
|
| - https://zulip.com/case-studies/lean/
|
| I know a bunch of the Rust people hang around on HN, maybe they
| can fill out any details or tell more about how it's going so far
| with using Zulip :)
| ChrisSD wrote:
| It does take a bit of getting used to. Zulip is kind of a cross
| between chat and a forum.
|
| However, once I did get used to it I think it's been great.
| Organizing chat into defined topics is super useful for
| following discussions you're interested in, filtering out those
| you aren't and for keeping conversations going across time
| zones.
|
| It's more discoverable than chat but not as rigid as an actual
| forum. I feel it works well once the learning curve has been
| surmounted.
| tiffanyh wrote:
| It's most akin to email list serv.
| tabbott wrote:
| 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 open source communities, because
| improving the productivity of the global open source community
| is an important part of our mission as an organization.
|
| One of the largest such investments has been the native public
| access option (no account required!) that we released earlier
| this month:
|
| https://blog.zulip.com/2022/05/05/public-access-option/
|
| (I lead the Zulip project)
| KennyBlanken wrote:
| 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
| stavros wrote:
| 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.
| 0des wrote:
| Hello Stavros it appears we meet again. How much would
| you pay a developer to accomplish this task?
| oxff wrote:
| It is _so_ bad though.
| turtlebits wrote:
| To me, the UI is unfriendly/confusing. Not sure if I'm just
| used to Slack, but it is very hard to use.
|
| Simple things like stream messages only being displayed halfway
| down the viewport with no scrollbar making it seem like there
| are no earlier messages.
| alx__ wrote:
| Yeah the UI make me feel like it was designed by developers.
| Which is cool if you love a clunky utilitarian vibe. :)
| JoshMandel wrote:
| 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).
| sundarurfriend wrote:
| 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.
| stavros wrote:
| Plus it's fast, Slack is a vat of molasses and I hate my
| life every time I have to use it.
| [deleted]
| brink wrote:
| I've never used it. What's wrong with it?
| yonixw wrote:
| 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 more robust for me (even if slow).
| tabbott wrote:
| 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.)
| cocolos wrote:
| UI is not great.
| capableweb wrote:
| First time I used it, it was a bit confusing, as I didn't
| really know what to expect. Is it email? Live chat? A
| forum?
|
| Turns out, it's a bit of both, and trying to use it as any
| single one of them, will probably make it harder to use.
|
| Basically, I treat it as a live chat where it's easier to
| participate in different topics at the same time, Slack on
| steroids where everything is a "Thread" basically.
| distances wrote:
| Sounds similar to Flowdock model? I greatly preferred
| that and was so disappointed when Slack finally rolled
| out their version of threading. It felt almost useless in
| comparison.
|
| Alas, Flowdock is dead now and I've learned to embrace
| Slack as the better remaining alternative over Teams or
| Google Chat.
| drwoland wrote:
| I think it's better than slacks sidebar threaded reply. It
| also has better code blocks, less irritating pop up magic
| and no bots nagging you to fill in credentials all the
| time.
| Operyl wrote:
| That's what the grandparent comment said, what specifically
| do you find wrong with the UI? I for one really enjoy it
| and the keyboard shortcuts.
| [deleted]
| bachmeier wrote:
| 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.
| tabbott wrote:
| 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 :).
| philip1209 wrote:
| 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.
| vitro wrote:
| You can set up Alert words in your personal settings and when
| that word appears in the chat, you will get notified as well.
| bachmeier wrote:
| 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.
| KronisLV wrote:
| The carousel on the main page is very easily understandable,
| which is great!
|
| The whole topics (sub-channels, basically) idea seems interesting
| as well, though personally the solution itself seems pretty
| similar to two other great pieces of software out there:
| - Rocket.Chat https://rocket.chat/ (the Jitsi integration was
| especially nice) - Mattermost https://mattermost.com/
| (really simple to setup)
|
| Both of those also seemed serviceable, decently familiar and
| usable. I guess even Nextcloud Talk could work if that suits your
| environment better https://nextcloud.com/talk/ though personally
| it felt a little more barebones in comparison.
|
| Has anyone extensively used any of them and can share what
| details/differences jumped out at them? Admittedly, i probably
| missed most of those myself and just saw them as similar, self-
| hostable chat solutions.
| aidenn0 wrote:
| I haven't used Rocket.Chat, but I've used the other two:
|
| Threading feels bolted on in Mattermost, but is the primary
| feature of zulip.
|
| Think of Zulip as a realtime version of NNTP, and Mattermost as
| a more modern IRC with a "reply" feature. The "right" way to
| use Zulip and Mattermost is quite different, though each one
| can be easily used as an inferior version of the other.
| itao wrote:
| Disclaimer: PM at Mattermost
|
| We of course use our own product every day and when I first
| joined the company in 2019 I also found that threading felt
| "bolted on". Primarily because channels rendered everything
| in the same linear feed regardless if it was a message or
| comment so there wasn't much point in taking the time to
| first hit reply.
|
| However, Collapsed Reply Thread [0] has been a game changer
| for me and not only do I no longer feel that way about
| threading, my productivity would plunge without it. That
| feature has been in public beta since last summer [1] and
| will go into general availability in two weeks to officially
| become the "right" way to use Mattermost. Not to say that
| it's the same as Zulip, just sharing an updated perspective.
|
| [0] https://docs.mattermost.com/channels/organize-
| conversations....
|
| [1] https://mattermost.com/blog/collapsed-reply-threads-beta/
| tasubotadas wrote:
| I've tried moving my teams to mattermost now twice and
| always we ran into the issue that integration for live
| meetings was painful. Neither zoom nor Google meets was
| possible to set up in an easy to use manner so everybody
| could jump on a call when needed
| josephcsible wrote:
| Mattermost and Rocket.Chat are both open core. Zulip is really
| 100% FOSS.
| thallavajhula wrote:
| Why does this seem like a chat version of Kafka?
| wnolens wrote:
| 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.
| maccam94 wrote:
| The thread-first model is quite different from the free-for-all
| channel model in IRC/Slack. Imagine the chaos in your email
| inbox if messages didn't have subject lines or threads. Zulip
| makes it actually feasible to follow a chat conversation
| asynchronously, and it's much easier to manage how many
| notifications you get.
| stavros wrote:
| 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.
| wnolens wrote:
| 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.
| stavros wrote:
| 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.
| Strom wrote:
| As someone who has used Zulip for years, I consider the named
| threads to be _the reason_ to use Zulip. When used properly, it
| makes following discussions actually possible without being
| drowned by other concurrent messages. I 'd say Discord is
| superior in many other ways, but for me this one killer feature
| still makes me prefer Zulip for work.
| dgacmu wrote:
| Strongly agree. My small, fully remote startup uses it, and
| this is the big reason we switched away from slack. The name
| threads are simply terrific for making it a better way to
| manage communication.
| shakna wrote:
| For one, Zulip is a year older than Slack.
|
| However, it is still has a ton of bridges and other
| integrations, and all the shiny things you'd expect from Slack.
| sdevonoes wrote:
| 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.
| letmeinhere wrote:
| 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.
| m00dy wrote:
| great marketing, but again I can't see anything related to
| privacy.
| wongarsu wrote:
| It's very easy to self-host. The only real gotcha are mobile
| notifications, because those are sent through centralized
| servers not hosted by you (because of how mobile APIs work).
|
| You have to choose server-wide between sending none (very
| private), sending redacted notifications (somewhat private,
| somewhat useful) or sending the full message in the
| notification (they see all your messages, but very convenient).
| Or I guess you can modify the mobile client and set up your own
| push notifications.
| tabbott wrote:
| 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.
| stavros wrote:
| 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?
| tabbott wrote:
| 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.
| stavros wrote:
| 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.
| tabbott wrote:
| 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 :).
| tabbott wrote:
| We of course have a privacy policy
| (https://zulip.com/policies/privacy) and some security pages
| that touch on privacy (https://zulip.com/security/; https://zul
| ip.readthedocs.io/en/latest/production/security-m...) but we
| put a lot of care into privacy issues both in product design
| and in what vendors we use, and adding a dedicated page about
| privacy is near the top of our TODO list for the website.
|
| If anyone wants to help, I'd love links to privacy pages that
| folks really like and/or lists of questions that readers would
| like to see such a page clearly answer.
___________________________________________________________________
(page generated 2022-05-31 23:01 UTC)