30 ms·

Zulip 3.0: Threaded Open Source Team Chat

500 points by nicholasjbs 6y ago

agustif 6y ago
Threads are the new black. It looks cool, might try it before Slack.
- garborg 6y ago
  It's had that model way before Slack, et al., kind of bolted it on. I've participated lightly in a couple orgs that use Zulip. Zulip's model does a much better job of keeping convos from getting drowned out / lost when pushed off the page, so it's much easier to log in sporadically and meaningfully participate. The apps, especially mobile have rough edges, but I still prefer it to Slack and the like, fwiw.
  - brians 6y ago
    It's a descendant of Zephyr, a lovely chat system that had great success in the world of stable IPv4 addresses, statically assigned, but which really hasn't made the mobile transition acceptably. Namable threads are amazing.
- kitd 6y ago
  Cf. any usenet client
  - aloisdg 6y ago
    Both Reddit and HN do it right too.
chubot 6y ago
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 that my keystrokes get delayed.
- isbjorn16 6y ago
  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 isn't going to be the way for everyone, but when looking for a community chat option for friends, we uninstalled zulip in less than a day and ended up going with matrix. That didn't work super well for us at the time so we went with Mattermost, which much closer aligns to our chat preferences. The good news is there are tons of options for people to choose what fits best for them! That's super exciting!
  - chubot 6y ago
    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?lang=en 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.
    - isbjorn16 6y ago
      I'd suspect it depends on what you're using it for - our instance of chat is primarily roughly themed chat rooms where we can talk about video games and bitch about python or rust or scala or home improvement projects or the news. It's very much so a modern day AOL chatroom experience, and that's by desire. We have discourse for things that make sense for deep threading, but for the most part everyone ignores it and just uses the chatrooms or the fairly effervescent threading in MM (that is basically the same as Slack's). If you're looking for a more real-time mailing list type behavior though, then Slack or MM would be a terrible, terrible, terrible choice imo.
liquid153 6y ago
Can you do screensharing and audio call in Zulip?
- Jeaye 6y ago
  Zulip integrates with Jitsi Meet, so the video call button generates a unique Jitsi meeting link which everyone can join without installing anything or making an account.
  - tabbott 6y ago
    Also, new in this release: BigBlueButton (another OSS video/call project). This release removes Google Hangouts support (as Google killed it and rebranded it to Google Meet). Unfortunately, the Google Meet rebrand came with removing the API that was useful for third party tools like Zulip. I don't understand why they don't provide the brilliant API Jitsi has where you can just generate a URL containing a random meeting ID and everyone who clicks it gets the same meeting (which Google Hangouts did, at least if everyone was in the same G Suite team). We also support Zoom (though note that Zulip Cloud is stuck in their marketplace approval process as it has been for months; supposedly it'll get approved any day now). https://zulip.com/help/start-a-call https://zulip.com/help/start-a-call (And of course we're happy to integrate anything else that has a reasonable API)
    - j1elo 6y ago
      Is BigBlueButton, or Zoom, covering different use cases than Jisti? or they are offered just for the sake of offering alternatives?
chrismorgan 6y ago
I noticed the changed logo and favicon today. I’m not fond of it yet: I find the discontinuity in the middle of the Z crossstroke surprisingly disconcerting. At large sizes it might work out OK (though I’m not convinced, it’s still feeling unbalanced somehow), but at small sizes it really doesn’t work. Furthermore, they’ve changed the style of the “number of unread messages” badge on the favicon so that it’s bigger and less… neat, is probably the right word, having gone for the “write the number in a normal sort of a font on a semitransparent white background and sit that atop the original favicon” rather than writing the number in what’s essentially a small bitmap font without needing the semitransparent white bit; and given that style, it looks quite terrible on a dark background, which my tab bar is. It ends up looking like the icon is just a number on some indistinct mess, with no real substance of the logo left visible, where before it was a clearly-visible small number on a clear and distinct Zulip logo. It’s unfortunately fundamentally impossible to pull off the style they’ve changed to—you must know whether it’s going to be matted against a dark or light colour for it to work, and the web doesn’t give you that. (I really wish it did. Sure, there are a couple of workarounds like using the (prefers-color-scheme: dark) media query to guess that the tab bar is probably dark, and that if that doesn’t match it’s probably light, but that’s still wildly inaccurate and insufficient. It’s a big enough deal that I’d like browser manufacturers to come up with something.) In all this I do say that I’m not fond of it yet. It’ll doubtless feel more acceptable after a few days. But comparing my reasons for disliking it with other occasions when I’ve not liked change (either at first or forever), I don’t think it’s going to grow on me as much as many do.
- price 6y ago
  Thanks for the close look :-) We're aware that the favicon image doesn't come out great at small sizes. Right now it's one SVG for all sizes, and I expect we'll have tweaked PNGs specific to small sizes out soon. For the number-of-unreads bit: might I persuade you to make an account on chat.zulip.org and come give that feedback there? That way we can perhaps iterate on variations of it and you can discuss those too.
StavrosK 6y ago
I can't recommend Zulip enough. It made remote communication many times easier, it's a dream to use because it's faster than Slack (though that bar is so low you have to dig to find it) and Riot, and its keyboard navigation is second to none. The mental model might take an hour or two to click, but you can think of it as Slack rooms where the only thing you can do is open new threads (can't post messages in the room itself, only in the threads). I really really think everyone should try it, it's a big improvement.
- JoshTriplett 6y ago
  > The mental model might take an hour or two to click, but you can think of it as Slack rooms where the only thing you can do is open new threads (can't post messages in the room itself, only in the threads). I've used both Slack and Zulip, and I wouldn't describe it that way. Slack threads feel more "isolated" by default, hidden away from the conversation, and you have to go look at each one; a Slack channel where you can only create threads doesn't feel like it'd be as appealing a UI as Zulip. On Zulip, you can look at the entire stream to see messages from different threads in real-time, or you can look at just one thread and see only the messages from that thread.
  - StavrosK 6y ago
    Oh, yes, the UI is fantastic in how it handles this, but I was describing the general data structure. Some people had trouble grasping the mental model initially, and I found thinking of it in those terms helpful for figuring out what's going on.
    - JoshTriplett 6y ago
      Part of the reason I brought this up was that this is roughly how Zulip was first described to me, and my experience with threads in Slack made that sound really unappealing, which led me to avoid trying Zulip for quite some time. Once I finally tried it, it was completely different than I expected, and much better.
jamesponddotco 6y ago
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 rather avoid. And while we would love to just move to IRC, and WeeChat, lack of E2E encryption is a deal-breaker.
- abhigyank 6y ago
  There is a Zulip CLI client - https://github.com/zulip/zulip-terminal https://github.com/zulip/zulip-terminal .
  - jamesponddotco 6y ago
    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.
    - johnisgood 6y ago
      I suppose for private messages it would be relatively easy to implement that, or add OTR support or something.
- tapoxi 6y ago
  https://element.io/ https://element.io/ ? Like XMPP it supports federation, but Matrix is JSON instead of XML.
  - Ericson2314 6y ago
    Yes if you want an XMPP replacement with E2E you definitely want Matrix. (Element, formerly Riot, is the client by the company founded by the founders of Matrix.)
  - 6y ago
jjordan 6y ago
Zulip is fantastic, and any steps we can take to free ourselves from the walled gardens is a good one, IMO.
eigenspace 6y ago
A group of us in the Julia open source community have been trying to migrate to Zulip [1] from Slack. There's a lot of resistance from some community members, but those of us who made the switch are quite happy. The topics model is fantastic, having proper markdown and LaTeX support is also killer. The development team for Zulip is also really responsive and friendly. Coming from Slack, it was a breath of fresh air to be able to make an issue on their GitHub issue tracker and have fast, friendly thoughtful replies and quick action. [1] https://julialang.zulipchat.com/#recent_topics https://julialang.zulipchat.com/#recent_topics if you wanna check it out
- dTal 6y ago
  That's excellent news. Being locked out of the community by virtue of it being hosted on a proprietary service, requiring a proprietary code blob to access, was one of the biggest sour notes I had coming to Julia. (Now if only discourse.julialang.org links would render without Javascript!)
  - oehtXRwMkIs 6y ago
    Remind me of Rust with the added bonus of requiring a GitHub account to upload crates.
    - dijit 6y ago
      FWIW Rust has a zulip, I'm on it, it's the only community I'm part of on zulip. It's mostly frequented by the infrastructure teams. :) Apparently the compiler team is also >primarily< there: https://rust-lang.github.io/compiler-team/about/chat-platform/ https://rust-lang.github.io/compiler-team/about/chat-platfor...
    - PudgePacket 6y ago
      You can add crates from other registries or git urls. https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories https://doc.rust-lang.org/cargo/reference/specifying-depende...
fareesh 6y ago
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?
- eigenspace 6y ago
  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.
- tabbott 6y ago
  I notice you mention a pixel phone; are you by any change using mobile Chrome? I think this is https://github.com/zulip/zulip/issues/14943 https://github.com/zulip/zulip/issues/14943, which sadly didn't get fixed for this release but is being worked on. Generally Zulip's scrolling and view-switching is very smooth and a ton of work has gone into it (my view is that if an app that you use all day isn't snappy it's going to waste tons of your time). The short answer for how to make good scrolling performance (like any other performance work, really) is to profile, make sure you understand what's happening, and fix it. It can be hard to predict what makes things slow without doing so. (Fun fact: seemingly reasonable ways to use an emoji spritesheet with CSS can wreck scrolling performance).
  - fareesh 6y ago
    Seems to be the case. Scrolls fine on Firefox
dang 6y ago
If curious see also (related threads): 2019 https://news.ycombinator.com/item?id=19284321 https://news.ycombinator.com/item?id=19284321 2018 https://news.ycombinator.com/item?id=18400988 https://news.ycombinator.com/item?id=18400988 2018 https://news.ycombinator.com/item?id=17622987 https://news.ycombinator.com/item?id=17622987 2018 https://news.ycombinator.com/item?id=17622707 https://news.ycombinator.com/item?id=17622707 2018 https://news.ycombinator.com/item?id=16863675 https://news.ycombinator.com/item?id=16863675 2017 https://news.ycombinator.com/item?id=14506426 https://news.ycombinator.com/item?id=14506426 2015 https://news.ycombinator.com/item?id=10279961 https://news.ycombinator.com/item?id=10279961 2014 https://news.ycombinator.com/item?id=7419408 https://news.ycombinator.com/item?id=7419408
muska3 6y ago
Honestly I found Zulip way too confusing. Am I the only one?
- eigenspace 6y ago
  Not the only one for sure, but I suspect that the big reason people are confused by Zulip is that they're already used to another, different chat service and don't remember how confused they were by it in the start.
- cookiecaper 6y ago
  No, we've had several experienced users immediately disengage because they felt overwhelmed and/or confused (not using as synonyms here, but common related reactions) by the interface. Performance issues, especially on mobile, haven't helped. Most people are just annoyed that you aren't using their favorite chat app already. Zulip is promising but I think there's a little bit of a bubble around it here on HN. In the real world, its reception is much more mixed, and outside the context of software development, topic threads are awkward and difficult to manage.
hereisdx 6y ago
Apart from a user, I am also a contributor to the Zulip project, for the last ~7 months. The community is very helpful and for getting started with open source development, I can't recommend a better place. You get really high quality code reviews, get to participate in meaningful discussions on features and the development goals of the project, and developers constantly share lots of knowledge in streams like #learning about software development, tech, git, best practices and so on. Also, the documentation is very detailed and the codebase is very high quality. It's really easy to get started. You can find the github org here: https://github.com/zulip https://github.com/zulip
- cobbzilla 6y ago
  As a fellow Zulip user and minor contributor, I wholeheartedly agree. In addition to coordinating development teams on three continents, we also use Zulip as an integration hub. git commits go in the #commits channel, jenkins build status to #builds, and run-time errors to #errors. We use errbit (API-compatible Airbrake clone) for error reporting and Zulip didn't have an errbit integration. So I wrote one, and they integrated it within a few days. The Zulip team was super-responsive and easy to work with. It certainly helped that they had excellent docs on how to write integrations, and tons of examples. Go Zulip!
- tabbott 6y ago
  Thanks for the kind words! One of our goals as a project is to have a "teaching-quality" codebase, so this is no surprise. I think this is incredibly important and something every community open source project should strive for. An analogy I like to use is to think about the experience of contributing to your open source project as a product, so you should: * Do usability studies where you help a group of people try to get started with your product (I used to do this all the time at events like Python conference sprints pre-pandemic). The first few we did were eye-opening as nobody got anywhere without a lot of handholding, and I suspect that's common. * Make the development environment tooling Just Work and have a good support experience. * Write good documentation that thoughtfully explains the ideas one needs to understand to participate on your project. My strategy for this was to avoid explaining how things work to a contributor, and instead meet the need by spending a couple hours writing something like https://zulip.readthedocs.io/en/latest/subsystems/sending-messages.html https://zulip.readthedocs.io/en/latest/subsystems/sending-me... and send it to them. That way, even if that contributor bounces (as the vast majority of new people who show up to any volunteer organization do), I still used my time well. I'm planning a series of blog posts on building a successful open source community, since we've spent a lot of time thinking about how to make contributing to Zulip a great experience, and some ideas are subtle (E.g. the secret to being able to give high quality code reviews is equipping new contributors with the tooling and documentation to help them avoid problems before a reviewer even looks at it!), and I regret not having spent more time sharing that thinking.
timwis 6y ago
I love the idea of this, but I’m trying to move my team away from synchronous communication. That tends to put us back in email, though that has its own problems. What is the asynchronous version of zulip? Forums?
- price 6y ago
  The asynchronous version of Zulip is Zulip. :-) A thing I really like about how Zulip works is that a conversation can happen asynchronously just like email, as well as synchronously. And the same conversation can shift smoothly from one to the other and back. I work on Zulip, and we basically don't use email at all - it's all either in Zulip or on a GitHub thread. (And the interesting discussions, I increasingly try to make sure to do on Zulip because GitHub is such a frustrating place to have a conversation.)
  - molsongolden 6y ago
    Adding on to +1 this. Zulip is great for async communication because it surfaces unread messages in an easy to skim and non-overwhelming way. After a day of not checking Zulip, the user can then open the chat and (before seeing any actual messages) see: 1) which streams have had activity. 2) which threads/topics within those streams have had activity. then choose which topics to read in a "relevant to me, not relevant to me" quick skim. Having the topics within streams also allows those topic discussions to persist over time without being lost in the deluge of other messages. There might be thousands of other chat messages between when I ask a question in #frontend > supercool.js but a teammate will skim later, see #frontend > supercool.js [1] and think "hey I know about supercool.js, what's up?" then respond. I can also search to see if there's already a supercool.js topic thread and catch up on what we've discussed in the past.
- wott 6y ago
  > That tends to put us back in email, though that has its own problems. What is the asynchronous version of zulip? Forums? Newsgroups (NNTP)? (I don't know Zulip and I don't know what problems you have with e-mail, so that's just a guess.)
- 6y ago
monadic2 6y ago
How is the experience of trying to find a conversation from a few months ago?
- tabbott 6y ago
  A big benefit of the organization provided by every message being in a topic is that it makes finding this more efficient. E.g. if you remember that Steve made a joke about donuts in the conversation, you can search for messages sent by Steve mentioning donuts, find the topic, and from there find the actual conversation. I do this to find months-old or years-old conversations several times a week. If you're curious to hear more, https://monadical.com/posts/how-to-make-remote-work-part-two-zulip.html https://monadical.com/posts/how-to-make-remote-work-part-two... talks about this idea in more detail. I also highly recommend making use of Zulip permalinks to conversations in issue trackers and other resources -- my anecdotal sense is most projects using Zulip do that a lot (the Zulip development team certainly does). Certainly the main feedback we've gotten on the zulip.com domain transition is "Will my permalinks keep working???". (Yes, they will).
bovermyer 6y ago
I would love to use this, but I don't manage any communities that aren't already married to either Discord or Slack.
- tabbott 6y ago
  FWIW we have been seeing a lot of larger communities that previously were deadset on Slack because "everyone knows it" importing their data from Slack in the last few months. Part of the reason is that Zulip's topics make it a lot easier for a part-time participant to use their limited time well (E.g. skimming or reading the conversations in most relevant to them in batch a few times a week). The Slack/Discord/IRC/etc. data model limits how effectively one can participate and benefit from a high-traffic organization without constantly watching it (and being in the organization's dominant time zone!). More on the inclusivity issues with synchronous chat here: https://zulip.com/for/open-source/ https://zulip.com/for/open-source/
  - bovermyer 6y ago
    Awesome. Well, I have no users because there's no community yet, but I did set up a Zulip (cloud) for my Iron Arachne project. I plan on linking to it from the website's main menu.
- pantaloony 6y ago
  Man, do I ever miss chat services and chat clients not being so tightly coupled to one another.
evacchi 6y ago
Zulip is great! We've been using it for kie.zulipchat.com (Drools, jBPM, OptaPlanner, Kogito). Quarkus team uses it too. Can't recommend it enough. Only downside so far, you can't mute private conversations. Overall great experience, though; threads really work.
micimize 6y ago
I find Zulip really promising, but lack of topic archival has always been troubling to me: https://github.com/zulip/zulip/issues/11154 https://github.com/zulip/zulip/issues/11154 Aside from that, I think it's biggest potential killer feature is tight issue thread integration: https://github.com/zulip/zulip/issues/12340 https://github.com/zulip/zulip/issues/12340 Very exciting project
nikisweeting 6y ago
Zulip has been absolutely pivotal in our company's remote work setup. It becomes a searchable knolwledgebase as a side-effect of its threading model (the exact opposite of the pile of unorganized mess that Slack usually devolves into): https://monadical.com/posts/how-to-make-remote-work-part-two-zulip.html https://monadical.com/posts/how-to-make-remote-work-part-two...
- apkallum 6y ago
  Seconding this as employee of said company : )
- krisreddy 6y ago
  I dont get why everyone thinks that searching for anything in a chat system is a good idea. This has nothing to do with how good the search engine is within the system. Because of Slack's inadequate design, they promoted searching, and now everyone thinks search is a MUST. If you really have to search in chat, I say you already have done something wrong. If searching in an email system, with its vastly more structured data, is itself inefficient, why would anyone think searching in chat is a good idea?
  - varispeed 6y ago
    Well, if you discussed some detail and can't remember which channel / thread it was on then the search is a must. I could agree that search may not be needed for a small team of a couple of people, but large teams with dozens of channels and topics should be able to search them to find required information.
    - krisreddy 6y ago
      If thats the scenario you think search is most applicable for, you are going to be sorely disappointed. Firstly you have to remember what it is you are looking for. Even if you do, the information is hidden in so many channels that you are unlikely to find what you are looking for without some effort. I think the best search is no search at all. Searching makes sennse for VERY large universe of data, as in WWW. The sheer volume makes creation of optimized search engine a profitable one. But a small universe search engine is inherently sub-optiomal, & is going to make the user sift through the "results" to find what they are looking for.
tiffanyh 6y ago
I recently was in the Zulip community design stream and the topic of their UI came up. I absolutely love Zulip but I’m afraid the design keeps folks from joining. There was a recommendation for it to update their design to be more like Discord new light theme [1] or Twist [2]. Twist is the more fair comparable since they are both Thread based (like email subject line) it’s just that Twist isn’t open source. [1] https://miro.medium.com/max/4050/1*iwfLW4rnn6U-mlUQpmBAfg.png https://miro.medium.com/max/4050/1*iwfLW4rnn6U-mlUQpmBAfg.pn... [2] https://get.twist.help/hc/article_attachments/115005750965/inbox.png https://get.twist.help/hc/article_attachments/115005750965/i...
JoshTriplett 6y ago
The Rust community uses Zulip heavily; I'm on it every day. Before I tried it, I was a little resistant to "yet another chat platform", and I didn't know how easily the threading model would work. Once I tried it, I got used to it very quickly, and started very much enjoying it. I'd highly recommend it. I also think it works well with automation; bots can create threads, and do things in response to messages in those threads.
switch007 6y ago
I remember coming across the Django part of the project a while ago and thought it was quite nice and pretty. Neither over-engineered nor under. https://github.com/zulip/zulip/tree/master/zerver/lib https://github.com/zulip/zulip/tree/master/zerver/lib
awill 6y ago
Is Dropbox still involved with this at all? It surprises me that Dropbox didn't integrate Zulip better, or combine it with Dropbox, Paper etc.. to create some kind of G Suite competitor.
- price 6y ago
  Dropbox is not involved with Zulip. I'm not sure we've ever posted a good canonical write-up of that story, but here's a version I wrote a couple of years ago: https://news.ycombinator.com/item?id=17629329 https://news.ycombinator.com/item?id=17629329
  - awill 6y ago
    Thanks for the background. So it sounds like Zulip was purely an acquihire.
    - lwf 6y ago
      [First engineer at Zulip; work at Dropbox] Portions of Zulip's backend were used to power some Dropbox features in 2014-16, but the product itself wasn't further integrated. In any case, I'm proud of how we handled the handoff to OSS and a sustainable independent stewardship org. I have https://ourincrediblejourney.tumblr.com/post/146708555778/zulip https://ourincrediblejourney.tumblr.com/post/146708555778/zu... framed on my wall.
zaphod4prez 6y ago
LOVE zulip!
sandGorgon 6y ago
Does Zulip have India/Asia pricing? Slack has an exchange rate adjusted pricing which is much cheaper (in dollar terms) for people paying from India.
- tabbott 6y ago
  We don't at present have an official policy on it, but we'd certainly be open to creating one. (And of course one can always self-host). What is Slack's adjusted pricing in India/Asia? I don't see it advertised on their website.
  - sandGorgon 6y ago
    https://slack.com/intl/en-in/pricing https://slack.com/intl/en-in/pricing
spooneybarger 6y ago
We've been using Zulip for the Ponylang community for about 18 months now. It is by far our favorite tool in the "chat" category. And this release addresses three of our biggest gripes. We highly recommend.
- maneesh 6y ago
  What were the gripes?
hardwaresofton 6y ago
Made some small contributions to Zulip and I can confirm that their team (and leader) is super friendly, and it's actually relatively easy to self-host these days. My personal favorite thing about Zulip is the keyboard navigation and how much muscle memory you can build moving around threads/conversations. Of course there's also the actual markdown (not some weird variant).
AceJohnny2 6y ago
I found Slack's design discussion on how they decided for single-depth threads interesting. There's a balance to strike between powerful features and usability. https://medium.com/slack-design/threads-in-slack-a-long-design-journey-a7c3f410ecb4 https://medium.com/slack-design/threads-in-slack-a-long-desi... Of course, people here have self-selected for favoring threads, but Slack's attention to the silent negatives is interesting and a lesson in product design.
- fiter 6y ago
  It seems that the link to part 2 is broken. Here is a working link: https://medium.com/slack-design/threads-in-slack-a-long-design-journey-1c9b1af652c9 https://medium.com/slack-design/threads-in-slack-a-long-desi... In their testing, it does not seem like they prototyped an N-nested (indented) threading model like on Reddit or HN. I am not surprised that it would be hard to understand how all the replies fit together without such nesting.
- price 6y ago
  In the context of this post, an important thing to add is that threads in Zulip also have just a single level of hierarchy - it's not at all like the tree structure here on HN, or on Reddit. We've felt that single level is the right balance for having a conversation that someone else can come to an hour later and easily read and follow. The way it works in Zulip is quite different from Slack, though. Here's a description in another comment in this thread: https://news.ycombinator.com/item?id=23863588 https://news.ycombinator.com/item?id=23863588
mderazon 6y ago
Can anyone compare the threaded model to Google Chat threads ? Is it the same ?
- nikisweeting 6y ago
  Google chat is completely unthreaded as far as I can tell. Unless you mean Google Groups?
  - mderazon 6y ago
    The other other Google chat https://gsuite.google.com/products/chat/ https://gsuite.google.com/products/chat/ http://chat.google.com http://chat.google.com
    - philsnow 6y ago
      as far as I can tell those links are both to the same product, is that not the case?
      - mderazon 6y ago
        Yes, parent was asking what product I meant when I mentioned "Google Chat" since they have so many chat products. I am using Google Chat at work, and it is also threaded. I haven't used Zulip and was asking if it had a similar thread model. I find the Google Chat thread model convenient and makes sense. But that is more or less the only good thing I can say about this product.
    - nikisweeting 6y ago
      Woah wth I've never even seen this before. Since when does this exist? Is it cross-compatible with Hangouts at all?
      - mderazon 6y ago
        It is completely different product, any GSuite accounts gets this included for free. It has weird relationship with Hangouts. It was previously called "Hangouts Chat" but that was too confusing (doh) so they've changed it to "Google Chat" When someone sends you a message there, it sometimes pops in your Gmail Hangouts widget... So a lot of people are not aware it exists.
lathiat 6y ago
Sounds like this is a better UI for Slack Threads.. which they were doubling down on in twitter just this week.
dzonga 6y ago
the codebase is beatiful, however this is a nasty gem: https://github.com/zulip/zulip/blob/2374e25b941977e95493ebe474e9e2ae7fe050c5/zerver/models.py#L831 https://github.com/zulip/zulip/blob/2374e25b941977e95493ebe4.... if it was me, I would've broken that into at least 3 models
- aero31aero 6y ago
  Good point! When I was new to the Zulip codebase I thought the same but after a while, my views changed. Its a very long model (and file) but very linear and organized, so it doesn't have that usual set of problems for which we have the common wisdom of not having long classes or methods. Basically, for this you have to ask yourself why you want to split it and what would you split it to. If ultimately what we'll get is something like UserProfileA, UserProfileB, UserProfileC, then that's arguably worse than one long UserProfile.
- nikisweeting 6y ago
  Having worked in Django a lot I actually quite like big UserProfile models, they're significantly easier to manage at scale than several (often overlapping) smaller models. The migrations are less tedious, and it's easy to see "everything" for a given user in one place.
red2awn 6y ago
Congratulations to the Zulip team, this release looks awesome!
neumann 6y ago
I love Zulip. Not only does work smoothly and with no bugs, it was one of the least painful installs and maintenances of any recent service I've tried to self host. I've tried to get traction with it as a self hosted solution at a few orgs instead of cloud offerings, and often meet with resistance by ITS in party because of the pains of administering a lot of these products. However, one I have succeeded pushing it through the feedback has been, 'Great, it just worksout of the box. We don't have to deal with it regularly'.
erlend_sh 6y ago
Seeing as Zulip is growing ever closer to a chat/forum hybrid, I hope you’ll consider making Zulip instances browsable by guests, just like a Gitter or Discourse instance.
- Cyphase 6y ago
  The master issue for that project is https://github.com/zulip/zulip/issues/13172 https://github.com/zulip/zulip/issues/13172. It's being worked on and is considered a high priority. There's also an archive tool at https://github.com/zulip/zulip-archive https://github.com/zulip/zulip-archive.

500 points by nicholasjbs 6y ago

agustif 6y ago

Threads are the new black. It looks cool, might try it before Slack.

garborg 6y ago
It's had that model way before Slack, et al., kind of bolted it on. I've participated lightly in a couple orgs that use Zulip. Zulip's model does a much better job of keeping convos from getting drowned out / lost when pushed off the page, so it's much easier to log in sporadically and meaningfully participate. The apps, especially mobile have rough edges, but I still prefer it to Slack and the like, fwiw.
- brians 6y ago
  It's a descendant of Zephyr, a lovely chat system that had great success in the world of stable IPv4 addresses, statically assigned, but which really hasn't made the mobile transition acceptably. Namable threads are amazing.
kitd 6y ago
Cf. any usenet client
- aloisdg 6y ago
  Both Reddit and HN do it right too.

chubot 6y ago

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 that my keystrokes get delayed.

isbjorn16 6y ago
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 isn't going to be the way for everyone, but when looking for a community chat option for friends, we uninstalled zulip in less than a day and ended up going with matrix. That didn't work super well for us at the time so we went with Mattermost, which much closer aligns to our chat preferences. The good news is there are tons of options for people to choose what fits best for them! That's super exciting!
- chubot 6y ago
  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?lang=en 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.
  - isbjorn16 6y ago
    I'd suspect it depends on what you're using it for - our instance of chat is primarily roughly themed chat rooms where we can talk about video games and bitch about python or rust or scala or home improvement projects or the news. It's very much so a modern day AOL chatroom experience, and that's by desire. We have discourse for things that make sense for deep threading, but for the most part everyone ignores it and just uses the chatrooms or the fairly effervescent threading in MM (that is basically the same as Slack's). If you're looking for a more real-time mailing list type behavior though, then Slack or MM would be a terrible, terrible, terrible choice imo.

liquid153 6y ago

Can you do screensharing and audio call in Zulip?

Jeaye 6y ago
Zulip integrates with Jitsi Meet, so the video call button generates a unique Jitsi meeting link which everyone can join without installing anything or making an account.
- tabbott 6y ago
  Also, new in this release: BigBlueButton (another OSS video/call project). This release removes Google Hangouts support (as Google killed it and rebranded it to Google Meet). Unfortunately, the Google Meet rebrand came with removing the API that was useful for third party tools like Zulip. I don't understand why they don't provide the brilliant API Jitsi has where you can just generate a URL containing a random meeting ID and everyone who clicks it gets the same meeting (which Google Hangouts did, at least if everyone was in the same G Suite team). We also support Zoom (though note that Zulip Cloud is stuck in their marketplace approval process as it has been for months; supposedly it'll get approved any day now). https://zulip.com/help/start-a-call https://zulip.com/help/start-a-call (And of course we're happy to integrate anything else that has a reasonable API)
  - j1elo 6y ago
    Is BigBlueButton, or Zoom, covering different use cases than Jisti? or they are offered just for the sake of offering alternatives?

chrismorgan 6y ago

I noticed the changed logo and favicon today. I’m not fond of it yet: I find the discontinuity in the middle of the Z crossstroke surprisingly disconcerting. At large sizes it might work out OK (though I’m not convinced, it’s still feeling unbalanced somehow), but at small sizes it really doesn’t work. Furthermore, they’ve changed the style of the “number of unread messages” badge on the favicon so that it’s bigger and less… neat, is probably the right word, having gone for the “write the number in a normal sort of a font on a semitransparent white background and sit that atop the original favicon” rather than writing the number in what’s essentially a small bitmap font without needing the semitransparent white bit; and given that style, it looks quite terrible on a dark background, which my tab bar is. It ends up looking like the icon is just a number on some indistinct mess, with no real substance of the logo left visible, where before it was a clearly-visible small number on a clear and distinct Zulip logo. It’s unfortunately fundamentally impossible to pull off the style they’ve changed to—you must know whether it’s going to be matted against a dark or light colour for it to work, and the web doesn’t give you that. (I really wish it did. Sure, there are a couple of workarounds like using the (prefers-color-scheme: dark) media query to guess that the tab bar is probably dark, and that if that doesn’t match it’s probably light, but that’s still wildly inaccurate and insufficient. It’s a big enough deal that I’d like browser manufacturers to come up with something.) In all this I do say that I’m not fond of it yet. It’ll doubtless feel more acceptable after a few days. But comparing my reasons for disliking it with other occasions when I’ve not liked change (either at first or forever), I don’t think it’s going to grow on me as much as many do.

price 6y ago
Thanks for the close look :-) We're aware that the favicon image doesn't come out great at small sizes. Right now it's one SVG for all sizes, and I expect we'll have tweaked PNGs specific to small sizes out soon. For the number-of-unreads bit: might I persuade you to make an account on chat.zulip.org and come give that feedback there? That way we can perhaps iterate on variations of it and you can discuss those too.

StavrosK 6y ago

I can't recommend Zulip enough. It made remote communication many times easier, it's a dream to use because it's faster than Slack (though that bar is so low you have to dig to find it) and Riot, and its keyboard navigation is second to none. The mental model might take an hour or two to click, but you can think of it as Slack rooms where the only thing you can do is open new threads (can't post messages in the room itself, only in the threads). I really really think everyone should try it, it's a big improvement.

JoshTriplett 6y ago
> The mental model might take an hour or two to click, but you can think of it as Slack rooms where the only thing you can do is open new threads (can't post messages in the room itself, only in the threads). I've used both Slack and Zulip, and I wouldn't describe it that way. Slack threads feel more "isolated" by default, hidden away from the conversation, and you have to go look at each one; a Slack channel where you can only create threads doesn't feel like it'd be as appealing a UI as Zulip. On Zulip, you can look at the entire stream to see messages from different threads in real-time, or you can look at just one thread and see only the messages from that thread.
- StavrosK 6y ago
  Oh, yes, the UI is fantastic in how it handles this, but I was describing the general data structure. Some people had trouble grasping the mental model initially, and I found thinking of it in those terms helpful for figuring out what's going on.
  - JoshTriplett 6y ago
    Part of the reason I brought this up was that this is roughly how Zulip was first described to me, and my experience with threads in Slack made that sound really unappealing, which led me to avoid trying Zulip for quite some time. Once I finally tried it, it was completely different than I expected, and much better.

jamesponddotco 6y ago

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 rather avoid. And while we would love to just move to IRC, and WeeChat, lack of E2E encryption is a deal-breaker.

abhigyank 6y ago
There is a Zulip CLI client - https://github.com/zulip/zulip-terminal https://github.com/zulip/zulip-terminal .
- jamesponddotco 6y ago
  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.
  - johnisgood 6y ago
    I suppose for private messages it would be relatively easy to implement that, or add OTR support or something.
tapoxi 6y ago
https://element.io/ https://element.io/ ? Like XMPP it supports federation, but Matrix is JSON instead of XML.
- Ericson2314 6y ago
  Yes if you want an XMPP replacement with E2E you definitely want Matrix. (Element, formerly Riot, is the client by the company founded by the founders of Matrix.)
- 6y ago

jjordan 6y ago

Zulip is fantastic, and any steps we can take to free ourselves from the walled gardens is a good one, IMO.

eigenspace 6y ago

A group of us in the Julia open source community have been trying to migrate to Zulip [1] from Slack. There's a lot of resistance from some community members, but those of us who made the switch are quite happy. The topics model is fantastic, having proper markdown and LaTeX support is also killer. The development team for Zulip is also really responsive and friendly. Coming from Slack, it was a breath of fresh air to be able to make an issue on their GitHub issue tracker and have fast, friendly thoughtful replies and quick action. [1] https://julialang.zulipchat.com/#recent_topics https://julialang.zulipchat.com/#recent_topics if you wanna check it out

dTal 6y ago
That's excellent news. Being locked out of the community by virtue of it being hosted on a proprietary service, requiring a proprietary code blob to access, was one of the biggest sour notes I had coming to Julia. (Now if only discourse.julialang.org links would render without Javascript!)
- oehtXRwMkIs 6y ago
  Remind me of Rust with the added bonus of requiring a GitHub account to upload crates.
  - dijit 6y ago
    FWIW Rust has a zulip, I'm on it, it's the only community I'm part of on zulip. It's mostly frequented by the infrastructure teams. :) Apparently the compiler team is also >primarily< there: https://rust-lang.github.io/compiler-team/about/chat-platform/ https://rust-lang.github.io/compiler-team/about/chat-platfor...
  - PudgePacket 6y ago
    You can add crates from other registries or git urls. https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories https://doc.rust-lang.org/cargo/reference/specifying-depende...

fareesh 6y ago

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?

eigenspace 6y ago
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.
tabbott 6y ago
I notice you mention a pixel phone; are you by any change using mobile Chrome? I think this is https://github.com/zulip/zulip/issues/14943 https://github.com/zulip/zulip/issues/14943, which sadly didn't get fixed for this release but is being worked on. Generally Zulip's scrolling and view-switching is very smooth and a ton of work has gone into it (my view is that if an app that you use all day isn't snappy it's going to waste tons of your time). The short answer for how to make good scrolling performance (like any other performance work, really) is to profile, make sure you understand what's happening, and fix it. It can be hard to predict what makes things slow without doing so. (Fun fact: seemingly reasonable ways to use an emoji spritesheet with CSS can wreck scrolling performance).
- fareesh 6y ago
  Seems to be the case. Scrolls fine on Firefox

dang 6y ago

If curious see also (related threads): 2019 https://news.ycombinator.com/item?id=19284321 https://news.ycombinator.com/item?id=19284321 2018 https://news.ycombinator.com/item?id=18400988 https://news.ycombinator.com/item?id=18400988 2018 https://news.ycombinator.com/item?id=17622987 https://news.ycombinator.com/item?id=17622987 2018 https://news.ycombinator.com/item?id=17622707 https://news.ycombinator.com/item?id=17622707 2018 https://news.ycombinator.com/item?id=16863675 https://news.ycombinator.com/item?id=16863675 2017 https://news.ycombinator.com/item?id=14506426 https://news.ycombinator.com/item?id=14506426 2015 https://news.ycombinator.com/item?id=10279961 https://news.ycombinator.com/item?id=10279961 2014 https://news.ycombinator.com/item?id=7419408 https://news.ycombinator.com/item?id=7419408

muska3 6y ago

Honestly I found Zulip way too confusing. Am I the only one?

eigenspace 6y ago
Not the only one for sure, but I suspect that the big reason people are confused by Zulip is that they're already used to another, different chat service and don't remember how confused they were by it in the start.
cookiecaper 6y ago
No, we've had several experienced users immediately disengage because they felt overwhelmed and/or confused (not using as synonyms here, but common related reactions) by the interface. Performance issues, especially on mobile, haven't helped. Most people are just annoyed that you aren't using their favorite chat app already. Zulip is promising but I think there's a little bit of a bubble around it here on HN. In the real world, its reception is much more mixed, and outside the context of software development, topic threads are awkward and difficult to manage.

hereisdx 6y ago

Apart from a user, I am also a contributor to the Zulip project, for the last ~7 months. The community is very helpful and for getting started with open source development, I can't recommend a better place. You get really high quality code reviews, get to participate in meaningful discussions on features and the development goals of the project, and developers constantly share lots of knowledge in streams like #learning about software development, tech, git, best practices and so on. Also, the documentation is very detailed and the codebase is very high quality. It's really easy to get started. You can find the github org here: https://github.com/zulip https://github.com/zulip

cobbzilla 6y ago
As a fellow Zulip user and minor contributor, I wholeheartedly agree. In addition to coordinating development teams on three continents, we also use Zulip as an integration hub. git commits go in the #commits channel, jenkins build status to #builds, and run-time errors to #errors. We use errbit (API-compatible Airbrake clone) for error reporting and Zulip didn't have an errbit integration. So I wrote one, and they integrated it within a few days. The Zulip team was super-responsive and easy to work with. It certainly helped that they had excellent docs on how to write integrations, and tons of examples. Go Zulip!
tabbott 6y ago
Thanks for the kind words! One of our goals as a project is to have a "teaching-quality" codebase, so this is no surprise. I think this is incredibly important and something every community open source project should strive for. An analogy I like to use is to think about the experience of contributing to your open source project as a product, so you should: * Do usability studies where you help a group of people try to get started with your product (I used to do this all the time at events like Python conference sprints pre-pandemic). The first few we did were eye-opening as nobody got anywhere without a lot of handholding, and I suspect that's common. * Make the development environment tooling Just Work and have a good support experience. * Write good documentation that thoughtfully explains the ideas one needs to understand to participate on your project. My strategy for this was to avoid explaining how things work to a contributor, and instead meet the need by spending a couple hours writing something like https://zulip.readthedocs.io/en/latest/subsystems/sending-messages.html https://zulip.readthedocs.io/en/latest/subsystems/sending-me... and send it to them. That way, even if that contributor bounces (as the vast majority of new people who show up to any volunteer organization do), I still used my time well. I'm planning a series of blog posts on building a successful open source community, since we've spent a lot of time thinking about how to make contributing to Zulip a great experience, and some ideas are subtle (E.g. the secret to being able to give high quality code reviews is equipping new contributors with the tooling and documentation to help them avoid problems before a reviewer even looks at it!), and I regret not having spent more time sharing that thinking.

timwis 6y ago

I love the idea of this, but I’m trying to move my team away from synchronous communication. That tends to put us back in email, though that has its own problems. What is the asynchronous version of zulip? Forums?

price 6y ago
The asynchronous version of Zulip is Zulip. :-) A thing I really like about how Zulip works is that a conversation can happen asynchronously just like email, as well as synchronously. And the same conversation can shift smoothly from one to the other and back. I work on Zulip, and we basically don't use email at all - it's all either in Zulip or on a GitHub thread. (And the interesting discussions, I increasingly try to make sure to do on Zulip because GitHub is such a frustrating place to have a conversation.)
- molsongolden 6y ago
  Adding on to +1 this. Zulip is great for async communication because it surfaces unread messages in an easy to skim and non-overwhelming way. After a day of not checking Zulip, the user can then open the chat and (before seeing any actual messages) see: 1) which streams have had activity. 2) which threads/topics within those streams have had activity. then choose which topics to read in a "relevant to me, not relevant to me" quick skim. Having the topics within streams also allows those topic discussions to persist over time without being lost in the deluge of other messages. There might be thousands of other chat messages between when I ask a question in #frontend > supercool.js but a teammate will skim later, see #frontend > supercool.js [1] and think "hey I know about supercool.js, what's up?" then respond. I can also search to see if there's already a supercool.js topic thread and catch up on what we've discussed in the past.
wott 6y ago
> That tends to put us back in email, though that has its own problems. What is the asynchronous version of zulip? Forums? Newsgroups (NNTP)? (I don't know Zulip and I don't know what problems you have with e-mail, so that's just a guess.)
6y ago

monadic2 6y ago

How is the experience of trying to find a conversation from a few months ago?

tabbott 6y ago
A big benefit of the organization provided by every message being in a topic is that it makes finding this more efficient. E.g. if you remember that Steve made a joke about donuts in the conversation, you can search for messages sent by Steve mentioning donuts, find the topic, and from there find the actual conversation. I do this to find months-old or years-old conversations several times a week. If you're curious to hear more, https://monadical.com/posts/how-to-make-remote-work-part-two-zulip.html https://monadical.com/posts/how-to-make-remote-work-part-two... talks about this idea in more detail. I also highly recommend making use of Zulip permalinks to conversations in issue trackers and other resources -- my anecdotal sense is most projects using Zulip do that a lot (the Zulip development team certainly does). Certainly the main feedback we've gotten on the zulip.com domain transition is "Will my permalinks keep working???". (Yes, they will).

bovermyer 6y ago

I would love to use this, but I don't manage any communities that aren't already married to either Discord or Slack.

tabbott 6y ago
FWIW we have been seeing a lot of larger communities that previously were deadset on Slack because "everyone knows it" importing their data from Slack in the last few months. Part of the reason is that Zulip's topics make it a lot easier for a part-time participant to use their limited time well (E.g. skimming or reading the conversations in most relevant to them in batch a few times a week). The Slack/Discord/IRC/etc. data model limits how effectively one can participate and benefit from a high-traffic organization without constantly watching it (and being in the organization's dominant time zone!). More on the inclusivity issues with synchronous chat here: https://zulip.com/for/open-source/ https://zulip.com/for/open-source/
- bovermyer 6y ago
  Awesome. Well, I have no users because there's no community yet, but I did set up a Zulip (cloud) for my Iron Arachne project. I plan on linking to it from the website's main menu.
pantaloony 6y ago
Man, do I ever miss chat services and chat clients not being so tightly coupled to one another.

evacchi 6y ago

Zulip is great! We've been using it for kie.zulipchat.com (Drools, jBPM, OptaPlanner, Kogito). Quarkus team uses it too. Can't recommend it enough. Only downside so far, you can't mute private conversations. Overall great experience, though; threads really work.

micimize 6y ago

I find Zulip really promising, but lack of topic archival has always been troubling to me: https://github.com/zulip/zulip/issues/11154 https://github.com/zulip/zulip/issues/11154 Aside from that, I think it's biggest potential killer feature is tight issue thread integration: https://github.com/zulip/zulip/issues/12340 https://github.com/zulip/zulip/issues/12340 Very exciting project

nikisweeting 6y ago

Zulip has been absolutely pivotal in our company's remote work setup. It becomes a searchable knolwledgebase as a side-effect of its threading model (the exact opposite of the pile of unorganized mess that Slack usually devolves into): https://monadical.com/posts/how-to-make-remote-work-part-two-zulip.html https://monadical.com/posts/how-to-make-remote-work-part-two...

apkallum 6y ago
Seconding this as employee of said company : )
krisreddy 6y ago
I dont get why everyone thinks that searching for anything in a chat system is a good idea. This has nothing to do with how good the search engine is within the system. Because of Slack's inadequate design, they promoted searching, and now everyone thinks search is a MUST. If you really have to search in chat, I say you already have done something wrong. If searching in an email system, with its vastly more structured data, is itself inefficient, why would anyone think searching in chat is a good idea?
- varispeed 6y ago
  Well, if you discussed some detail and can't remember which channel / thread it was on then the search is a must. I could agree that search may not be needed for a small team of a couple of people, but large teams with dozens of channels and topics should be able to search them to find required information.
  - krisreddy 6y ago
    If thats the scenario you think search is most applicable for, you are going to be sorely disappointed. Firstly you have to remember what it is you are looking for. Even if you do, the information is hidden in so many channels that you are unlikely to find what you are looking for without some effort. I think the best search is no search at all. Searching makes sennse for VERY large universe of data, as in WWW. The sheer volume makes creation of optimized search engine a profitable one. But a small universe search engine is inherently sub-optiomal, & is going to make the user sift through the "results" to find what they are looking for.

tiffanyh 6y ago

I recently was in the Zulip community design stream and the topic of their UI came up. I absolutely love Zulip but I’m afraid the design keeps folks from joining. There was a recommendation for it to update their design to be more like Discord new light theme [1] or Twist [2]. Twist is the more fair comparable since they are both Thread based (like email subject line) it’s just that Twist isn’t open source. [1] https://miro.medium.com/max/4050/1*iwfLW4rnn6U-mlUQpmBAfg.png https://miro.medium.com/max/4050/1*iwfLW4rnn6U-mlUQpmBAfg.pn... [2] https://get.twist.help/hc/article_attachments/115005750965/inbox.png https://get.twist.help/hc/article_attachments/115005750965/i...

JoshTriplett 6y ago

The Rust community uses Zulip heavily; I'm on it every day. Before I tried it, I was a little resistant to "yet another chat platform", and I didn't know how easily the threading model would work. Once I tried it, I got used to it very quickly, and started very much enjoying it. I'd highly recommend it. I also think it works well with automation; bots can create threads, and do things in response to messages in those threads.

switch007 6y ago

I remember coming across the Django part of the project a while ago and thought it was quite nice and pretty. Neither over-engineered nor under. https://github.com/zulip/zulip/tree/master/zerver/lib https://github.com/zulip/zulip/tree/master/zerver/lib

awill 6y ago

Is Dropbox still involved with this at all? It surprises me that Dropbox didn't integrate Zulip better, or combine it with Dropbox, Paper etc.. to create some kind of G Suite competitor.

price 6y ago
Dropbox is not involved with Zulip. I'm not sure we've ever posted a good canonical write-up of that story, but here's a version I wrote a couple of years ago: https://news.ycombinator.com/item?id=17629329 https://news.ycombinator.com/item?id=17629329
- awill 6y ago
  Thanks for the background. So it sounds like Zulip was purely an acquihire.
  - lwf 6y ago
    [First engineer at Zulip; work at Dropbox] Portions of Zulip's backend were used to power some Dropbox features in 2014-16, but the product itself wasn't further integrated. In any case, I'm proud of how we handled the handoff to OSS and a sustainable independent stewardship org. I have https://ourincrediblejourney.tumblr.com/post/146708555778/zulip https://ourincrediblejourney.tumblr.com/post/146708555778/zu... framed on my wall.

zaphod4prez 6y ago

LOVE zulip!

sandGorgon 6y ago

Does Zulip have India/Asia pricing? Slack has an exchange rate adjusted pricing which is much cheaper (in dollar terms) for people paying from India.

tabbott 6y ago
We don't at present have an official policy on it, but we'd certainly be open to creating one. (And of course one can always self-host). What is Slack's adjusted pricing in India/Asia? I don't see it advertised on their website.
- sandGorgon 6y ago
  https://slack.com/intl/en-in/pricing https://slack.com/intl/en-in/pricing

spooneybarger 6y ago

We've been using Zulip for the Ponylang community for about 18 months now. It is by far our favorite tool in the "chat" category. And this release addresses three of our biggest gripes. We highly recommend.

maneesh 6y ago
What were the gripes?

hardwaresofton 6y ago

Made some small contributions to Zulip and I can confirm that their team (and leader) is super friendly, and it's actually relatively easy to self-host these days. My personal favorite thing about Zulip is the keyboard navigation and how much muscle memory you can build moving around threads/conversations. Of course there's also the actual markdown (not some weird variant).

AceJohnny2 6y ago

I found Slack's design discussion on how they decided for single-depth threads interesting. There's a balance to strike between powerful features and usability. https://medium.com/slack-design/threads-in-slack-a-long-design-journey-a7c3f410ecb4 https://medium.com/slack-design/threads-in-slack-a-long-desi... Of course, people here have self-selected for favoring threads, but Slack's attention to the silent negatives is interesting and a lesson in product design.

fiter 6y ago
It seems that the link to part 2 is broken. Here is a working link: https://medium.com/slack-design/threads-in-slack-a-long-design-journey-1c9b1af652c9 https://medium.com/slack-design/threads-in-slack-a-long-desi... In their testing, it does not seem like they prototyped an N-nested (indented) threading model like on Reddit or HN. I am not surprised that it would be hard to understand how all the replies fit together without such nesting.
price 6y ago
In the context of this post, an important thing to add is that threads in Zulip also have just a single level of hierarchy - it's not at all like the tree structure here on HN, or on Reddit. We've felt that single level is the right balance for having a conversation that someone else can come to an hour later and easily read and follow. The way it works in Zulip is quite different from Slack, though. Here's a description in another comment in this thread: https://news.ycombinator.com/item?id=23863588 https://news.ycombinator.com/item?id=23863588

mderazon 6y ago

Can anyone compare the threaded model to Google Chat threads ? Is it the same ?

nikisweeting 6y ago
Google chat is completely unthreaded as far as I can tell. Unless you mean Google Groups?
- mderazon 6y ago
  The other other Google chat https://gsuite.google.com/products/chat/ https://gsuite.google.com/products/chat/ http://chat.google.com http://chat.google.com
  - philsnow 6y ago
    as far as I can tell those links are both to the same product, is that not the case?
    - mderazon 6y ago
      Yes, parent was asking what product I meant when I mentioned "Google Chat" since they have so many chat products. I am using Google Chat at work, and it is also threaded. I haven't used Zulip and was asking if it had a similar thread model. I find the Google Chat thread model convenient and makes sense. But that is more or less the only good thing I can say about this product.
  - nikisweeting 6y ago
    Woah wth I've never even seen this before. Since when does this exist? Is it cross-compatible with Hangouts at all?
    - mderazon 6y ago
      It is completely different product, any GSuite accounts gets this included for free. It has weird relationship with Hangouts. It was previously called "Hangouts Chat" but that was too confusing (doh) so they've changed it to "Google Chat" When someone sends you a message there, it sometimes pops in your Gmail Hangouts widget... So a lot of people are not aware it exists.

lathiat 6y ago

Sounds like this is a better UI for Slack Threads.. which they were doubling down on in twitter just this week.

dzonga 6y ago

the codebase is beatiful, however this is a nasty gem: https://github.com/zulip/zulip/blob/2374e25b941977e95493ebe474e9e2ae7fe050c5/zerver/models.py#L831 https://github.com/zulip/zulip/blob/2374e25b941977e95493ebe4.... if it was me, I would've broken that into at least 3 models

aero31aero 6y ago
Good point! When I was new to the Zulip codebase I thought the same but after a while, my views changed. Its a very long model (and file) but very linear and organized, so it doesn't have that usual set of problems for which we have the common wisdom of not having long classes or methods. Basically, for this you have to ask yourself why you want to split it and what would you split it to. If ultimately what we'll get is something like UserProfileA, UserProfileB, UserProfileC, then that's arguably worse than one long UserProfile.
nikisweeting 6y ago
Having worked in Django a lot I actually quite like big UserProfile models, they're significantly easier to manage at scale than several (often overlapping) smaller models. The migrations are less tedious, and it's easy to see "everything" for a given user in one place.

red2awn 6y ago

Congratulations to the Zulip team, this release looks awesome!

neumann 6y ago

I love Zulip. Not only does work smoothly and with no bugs, it was one of the least painful installs and maintenances of any recent service I've tried to self host. I've tried to get traction with it as a self hosted solution at a few orgs instead of cloud offerings, and often meet with resistance by ITS in party because of the pains of administering a lot of these products. However, one I have succeeded pushing it through the feedback has been, 'Great, it just worksout of the box. We don't have to deal with it regularly'.

erlend_sh 6y ago

Seeing as Zulip is growing ever closer to a chat/forum hybrid, I hope you’ll consider making Zulip instances browsable by guests, just like a Gitter or Discourse instance.

Cyphase 6y ago
The master issue for that project is https://github.com/zulip/zulip/issues/13172 https://github.com/zulip/zulip/issues/13172. It's being worked on and is considered a high priority. There's also an archive tool at https://github.com/zulip/zulip-archive https://github.com/zulip/zulip-archive.