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.
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.
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.
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!
Can't you just make a single "general" room and talk in there? Have you ever used Zulip? Your objection puzzles me a bit because I can't see how it's a problem, since your use case is trivially supported.
Yes, I've used zulip - every single comment spawned a thread or responded to a thread. Users weren't used to responding to a thread, which meant we had threads of single comments constantly. I'm puzzled that you're puzzled. I thought this was the way Zulip worked. It was about 2 years ago, at any rate. Did it change since then? If so, that's exciting in its own right.
Hmm, that sounds like something was going wrong, threads don't just spawn, you have to create them, and a thread with a single comment kind of defeats the purpose.
Oh, were you editing the subject every time you commented, maybe? That's not indicated, you only edit the subject when you want to create a new thread. In our use case, threads were relatively infrequent and specific to a topic, e.g. "middle name database migration", and that's where the discussion for that happened.
Somehow we had like 15 users and not one of them managed to make a comment that wasn't a new thread - like I said though, it was like 2 years ago. Either there was a bug, or it was a design decision, or maybe even a misconfiguration on the server - regardless it got a hearty thumbs down by the community and we went on to try matrix. I was hoping for Zulip since it was a way easier install than matrix + riotweb was, especially since we wanted to self host everything. In the end all the bugs we had in riotweb and the phone apps were enough for us to jump for MM, which has its own problems but was most in line with what we wanted.
Anyway, if Zulip isn't thread-first, then I guess it's less a competitor to Teams than I thought. The only way we found to make teams work for us and our very small team is to keep everything in a named joint chat and everyone utterly ignores the channels like the plague. It's always amusing when someone posts something to a channel for the first time in weeks/months and then people start responding thinking it's chat and every. single. response. becomes a new thread, because they didn't respond inside the original thread.
Every message (other than PMs) is within a topic thread which is within a stream.
This can be structured by having ongoing social threads but users do need to know that they should respond to existing "broad topic ongoing" threads instead of creating a new micro-thread for every message.
We structure the Streams into roughly:
- company-wide announcements
- org streams
- team streams
- social
then within #social you could have ongoing topics like "books", "weekend", "music", etc...
You can also restrict stream access as needed (only team members can view the team stream).
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.
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.
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.
> The good news is there are tons of options for people to choose what fits best for them! That's super exciting!
Personally I'm finding it a bit of a nightmare, as just about every community I'm interested in seems to require a different tool to be installed. Same for work clients.
Worse than that, some communities are fragmented into different IM tool groups.
The plethora of IM and other tools needed to stay vaguely involved in the leading edge conversation in multiple communities is a right pain for usability.
What I really want is some way to see an overview of conversations in multiple communities I'm interested in and interact with them through that. A single tool would be nice, but some way of visually integrating similar tools would be ok as well.
I was pretty happy with Pidgin for this many years ago, as it worked with almost everything. But even then I needed Skype separately. I don't think libpurple is quite as universal now.
I tend to use the web clients for everything for just this reason. Turning notifications on gives me the same toast behavior I'd have in a thick client and I'm not running 14 instances of electron at a time. I can see this being frustrating for you, though (just because I found something that works for me doesn't mean it'll work for everyone!)
That's a good suggestion, and as it happens I use web clients when possible as well.
That sucks in a different way, as the experience tends to be sub par, but at least it works (when on desktop - it's high friction when I've only got my phone to hand).
It's still much like having a different application for every community or work client though - only it's become a different tab for each of them, with the tabs organised by application rather than by usefulness (or there are too many tabs), which is a poor way to organise.
It also makes it difficult to organise information beyond the crude tools provided. Desktop notifications exist, yes, but I would find it so much more useful to be able to filter content and notify me of only relevant things, sort, pin, annotate, link and so on. And for this prioritisation and context management to mediate between different information sources globally, rather than having to use my own brain to do it manually, which I find to be a significant cognitive load.
As it's not there yet, it's not a solution for my requirement.
Eventually, maybe.
For now, I think using Matrix to bridge to every other service is quite daunting. Consider these instructions which seem to be needed to connect to a Telegram group:
I'm lucky that I can easily follow those instructions if I want. But to do all that just for 1 group?
The next one uses Slack.
Then Mattermost.
Then Discord.
Then IRC/Freenode.
My client uses MSN.
My other client uses Yahoo.
My other other client uses Skype.
A recruiter contacts me through WhatsApp, when I didn't have installed.
Another contacts me through LinkedIn.
Another through Telegram.
A friend sent me a message over Facebook Messenger. Of course I didn't get the Facebook message for 6 months due to not logging in :-)
(A friend of mine received a message over WhatsApp and didn't know for 12 months because of not having it installed at all, only to find someone they thought had stopped talking to them was actually sending WhatsApp messages, assuming of course everyone uses it.)
And then there are those group chats on Zoom sometimes.
I haven't listed them all...
Matrix has a long way to go before it's reasonably low effort to use seamless integration with all contact points that are coming up in practice.
I looked at Matrix recently, and it's very impressive how much has been implemented!
I'm almost certainly going to start using Matrix soon, if only because some communities I want to follow are on matrix.org itself.
But seamless, easy, and confident integration with many third party channels seems like it may be a long way off. (I'd also worry about messages getting lost or something due to services not integrating well with third party clients, especially given the adversarial relationship some services have.)
The problem is that everything and its pets seem to be using different services, and some of those want to live in walled gardens.
Amidst this, to be honest, I don't even use IM much! I'm not the chatting type.
But for key people or teams I need to use whatever they use, and for community awareness on the internet I want to see conversation where other people are discussing what I'm interested in, and pick up on key items sufficiently close to real-time to participate if I want.
Oh yeah, it absolutely has a long way to go before it's approachable for even the average power user. But I'm hopeful that with enough traction we will get to a better point than either libpurple (pidgin) or bitlbee before long.
I personally find threads better for actually getting work done while more focused chat like in Slack is better for “water cooler” talk. I know it isn’t the same for everyone, but I’ve found the orgs using Teams to be a bit more productive and a bit less chatty.
We found the basic models in Slack, Teams and Zulip too rigid. In all such clones of the Slack design, the members of channels (and threads) are static. You are either a participant in the entire channel or you arent. But it doesnt work like that in the real world.
For starters, a thread is a personal idea. (I think this is what you mean by opt-in). My idea of a thread is probably not your idea of a thread. So the concept of shared thread (channel) is hard to fathom. Second, my thread is made of activities I need to complete for the task at hand. In the process, I will interact with as many people or as few as I see fit, all in the pursuit of my goal.
Not all the people I interact with (thread participants) are necessarily members of my team. This is where the rigidity is a real problem with the aforementioned products. I cannot know all the participants at the time of channel creation. And once involve a non-team-member user in the thread, they become unwitting recipients of noise, and they cant do a damn thing about it.
You may not even need the app. Zulip on Android Firefox is a better experience for me than the app, personally. (Tho the web version was, oddly, severely laggy in mobile Chrome the one time I tried it, some time ago...)
The UI is somewhat confusing; also, it seems designed to give a view of particular, selected streams and topics of interest, and doesn't always seem to keep up even with those -- but volume on my server is low enough that I want "all messages", and if there's UI which does that reliably... it's not signposted well enough for me to find it before my patience ran out.
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.
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.
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.
> 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.
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.
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.
Oh, yes, that makes sense. I'm definitely not trying to entice people with that description, I more intend to help them understand what they're looking at when they do try it.
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.
I looked into it a couple of times, but most clients lack E2E encryption support, and the oficial ones are Electron monsters. We mostly work over SSH on remote workstations, hence the CLI/TUI requirement.
Altough, it seems there is a plugin for WeeChat with E2E encryption[1]. Gotta take a look.
E2E encryption kinda breaks with the model of Zulip, ie a company or a project where everything should be visible by everyone even if they arrive after the conversation has started. You'll probably be better served by hosting your own instance and trusting everyone who connects to it.
That is another thing, it would be even better if we could control E2E encryption per room.
Since we do everything in the open, instead of needing something like XMPP for private conversations, and IRC for public conversations, we could simply have private rooms with E2E encryption for the team, and public rooms for everyone else.
I wish IRC had E2E encryption.
In the end, I think we might stay with XMPP with OMEMO for private conversations — or Matrix, depending on how well weechat-matrix work —, and use mailing lists for public discussions. We already use them for patches anyway.
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.
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!)
I don't quite get this concern about proprietary JS. I agree JS can be malicious, but it has nothing to do with license. Or you can say you don't want to give your data to Slack.
I sympathize with those who object to proprietary JS, but in my case I'm mostly annoyed at having to run code just to read static content - quite heavy code, too. When I have a lot of discourse.julialang.org pages open, my browser noticeably chugs.
Nice, I wandered on to the Zulip Chatroom for Quarkus. It didn’t take me very long to figure out the interface: it was very intuitive, and I absolutely LOVE the syntax highlighting support AND topic centered conversations! For technical conversations when you gotta share a lot of code, it makes a HUGE difference when you can share code snippets that are easy to read. Slack allows this with the upload a snippet feature but it’s hard to use and the UX of snippets is kinda atrocious.
If I were to start a new community, I would absolutely go with Zulip.
Is there any sort of 1:1 syncing integration between slack and zulip? It would be awesome if posts in public channels would show up on either app, regardless which was posted -- would make transition easier for teams!
And -- if there isn't, if any developer is interested in working on it, I'd possibly be willing to pay -- and we could probably release it as open source! maneesh@pavlok.com
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.
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, 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).
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.
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.
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.
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).
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?
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.)
What are the problems with email? For me, it seems that having internal mailing lists that anyone can subscribe to (sometimes needing approval, like ceo-staff@) allows for structured topical threaded discussions that are archive able and searchable.
Other than one-off q&as, I don't understand why email isn't still the best thing we have?
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.
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).
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.
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.
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-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.
Thanks for you comment with interesting points. It’s quite different from the perspective of “scratching an itch” open source code. I look forward to your posts on nurturing open source communities.
Based on my simple analytics that looks at the time between a contributors first and last commit, I'm getting 50 active contributors, which matches up with many of the other popular open source projects I've indexed.
Also, that's just the server project. There are also clients like the mobile app and the terminal app, which have a whole new set of active contributors.
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:
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.
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):
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?
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.
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.
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.
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.
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
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).
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.
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.
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.
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.
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.
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.
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.
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'.
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.
reply