Zulip 4.0: Threaded open source team chat(blog.zulip.com)
blog.zulip.com
Zulip 4.0: Threaded open source team chat
https://blog.zulip.com/2021/05/13/zulip-4-0-released/
175 comments
The "threaded" part is key here. Slack threads are useless compared to Zulip. In Zulip you can create threads on the fly from existing messages, so if discussion starts diverging you can turn it into a new thread. It's just a fundamentally superior model.
Interesting. Threads in MS Teams utterly don't get used, they require significant self discipline to use properly (and yet they get more love from the devs than chat, somebody at MS is misguided in how the thing actually gets used).
IME using teams about a year ago- I hated threads. The "reply" section took up a massive amount of space on the screen for each message and replying to a message took it out of the chronology of the channel/team. It's possible that if everyone were disciplined enough to make sure that every chat message was a "topic" and kept everything as replies, maybe that would work. But in practice, that's not how conversations work and some of that is subjective. I'd much rather have everything in chronological order so that I can decide what is relevant context. Also, there was no way to turn it off as an admin at the time (there may be now), so even if we said "never use replies", people still sometimes did.
Discord's reply function is basically exactly what I want- It takes up no extra space, the message being replied to is not removed from its original context, and the reply shows a preview and lets you easily jump back to the original context.
Discord's reply function is basically exactly what I want- It takes up no extra space, the message being replied to is not removed from its original context, and the reply shows a preview and lets you easily jump back to the original context.
I see some people initially fail to use threads in Teams, but with appropriate peer pressure that doesn't last for long.
All it takes is disabling the bottom new thread creation box and replacing it with a button. That's what work did and it's so easily enforced on the creation of new threads.
Is this not just something MS Teams did? [1] You seem to be implying it's an optional setting or customization. I'm not an MS Teams admin, just a user on one instance of Teams, and was happy when the button appeared.
It stopped the broken conversations, but it didn't make anyone use MS Teams any more than necessary. (Our group has been using Slack for longer than Teams has been around, and since Teams is still inferior in nearly every way we haven't switched; due to the near silence from every other org in the company, they're probably doing the same).
[1] https://stitchdx.com/blog/microsoft-teams-new-conversation-b...
It stopped the broken conversations, but it didn't make anyone use MS Teams any more than necessary. (Our group has been using Slack for longer than Teams has been around, and since Teams is still inferior in nearly every way we haven't switched; due to the near silence from every other org in the company, they're probably doing the same).
[1] https://stitchdx.com/blog/microsoft-teams-new-conversation-b...
Interesting. I was assuming it was an admin who did it at my place of work.
We moved to teams from zooms ephemeral chats, and I have to say it's nicer in teams with all of the integrations and file storage.
We moved to teams from zooms ephemeral chats, and I have to say it's nicer in teams with all of the integrations and file storage.
I've had the opposite experience with Teams threads. I'm at a big company where about half the posts are made by non-technical people, and yet the threads seem to get used pretty well. For all the things I hate about Teams, they seem to have hit a sweet spot in that bit of UI where it's hard (but not impossible) to accidentally add to an existing thread with a new topic, or accidentally make a new thread when you were trying to reply to a post, and because of that things stay pretty organized.
By "threads" in MS teams, do you mean what they call a "conversation" in a normal channel? How do they not get used - people just 'start a new conversation' for every reply?
We get basically perfect usage of the conversation system at work (an engineering org), and so I've always thought that the MS implementation was the best. It has almost all of the organisation positives of Zulip threading without forcing you to name every single thread, and with none of the onboarding pain. We also have 'New Conversation' as a button as suggested by a sibling comment, so maybe that's the key.
I find it interesting that we both had fairly self-centred views on how much the conversation system was used. Don't forget that MS have the actual data!
We get basically perfect usage of the conversation system at work (an engineering org), and so I've always thought that the MS implementation was the best. It has almost all of the organisation positives of Zulip threading without forcing you to name every single thread, and with none of the onboarding pain. We also have 'New Conversation' as a button as suggested by a sibling comment, so maybe that's the key.
I find it interesting that we both had fairly self-centred views on how much the conversation system was used. Don't forget that MS have the actual data!
I've been using teams for almost a year and didn't know it had threads
Zulip is one of the very few software tools that I really find a joy to use, because they make it easy to work within the correct patterns.
Seriously, it's hard to express this experience until you've tried it. If you look at their feature lists, you can't appreciate the craft and love and thought put into Zulip that makes it stand out from other chat systems.
And you may live in the chat systems with your distributed teams all day.
Seriously, it's hard to express this experience until you've tried it. If you look at their feature lists, you can't appreciate the craft and love and thought put into Zulip that makes it stand out from other chat systems.
And you may live in the chat systems with your distributed teams all day.
My current company uses Slack and I groan every time I have to use it. I miss Zulip greatly.
[deleted]
Yep! I think the author highlights it well
> I received over 20,000 messages in chat.zulip.org during my paternity leave. I really enjoyed reading everything and replying to the hundreds of topics where I had something to contribute or someone to thank. Systematically reading months of history would have been impossible with any other tool!
> I received over 20,000 messages in chat.zulip.org during my paternity leave. I really enjoyed reading everything and replying to the hundreds of topics where I had something to contribute or someone to thank. Systematically reading months of history would have been impossible with any other tool!
Wait what? We are supposed to do that? My reaction after months long paternity leave to something like Slack messages would be "mark all read".
Fair enough, and depends on your FOMO -- but with Zulip's topics/threads you'd be the one who makes this call. E.g. you probably want to skip some banter or some operational stuff, but still catch up with the topics you want to catch up -- and at your own pace.
(Post author here)
I don't think most people need to read everything they receive, but in my role as the project leader of a large open source community, essentially every conversation in chat.zulip.org is potentially relevant for me, so skimming every conversation is useful.
The critical thing here, both in my daily work and coming back from time away, is that Zulip makes skimming really cheap (`n` to jump to next topic, then read a moment and then hit `End` if it seems likely that the thread is resolved to check the conclusion, and then repeat). So a 150-message thread debugging something takes like 30 seconds -- read the first post (maybe a bug report), note who was helping investigate, jump to send and see that the topic ends with a PR link or other resolution.
At the same time, Zulip's organization means I could find the dozen of threads that might be a short thread presenting a question or problem that I'm our main expert on. In these cases, I can read the thread carefully, and send a reply resurrecting the thread (2 months later) with answer that was missing, some added context/background, or a link to a PR I made to put the answer in our documentation (my preferred solution to unanswered questions).
This has the effect of unblocking a bunch of useful work that had been waiting for me to return, and also giving me good context on everything I missed.
It's also pretty fun to see all the great that folks did while I was away :)
I don't think most people need to read everything they receive, but in my role as the project leader of a large open source community, essentially every conversation in chat.zulip.org is potentially relevant for me, so skimming every conversation is useful.
The critical thing here, both in my daily work and coming back from time away, is that Zulip makes skimming really cheap (`n` to jump to next topic, then read a moment and then hit `End` if it seems likely that the thread is resolved to check the conclusion, and then repeat). So a 150-message thread debugging something takes like 30 seconds -- read the first post (maybe a bug report), note who was helping investigate, jump to send and see that the topic ends with a PR link or other resolution.
At the same time, Zulip's organization means I could find the dozen of threads that might be a short thread presenting a question or problem that I'm our main expert on. In these cases, I can read the thread carefully, and send a reply resurrecting the thread (2 months later) with answer that was missing, some added context/background, or a link to a PR I made to put the answer in our documentation (my preferred solution to unanswered questions).
This has the effect of unblocking a bunch of useful work that had been waiting for me to return, and also giving me good context on everything I missed.
It's also pretty fun to see all the great that folks did while I was away :)
Backing up from the special case of a paternity leave, what's important here is that with Zulip, catching up on conversations you missed is an efficient use of your time, which it really isn't for other team chat tools.
Essentially everyone has miniature versions of the catch-up problem:
* Fulltime employees coming back from a normal 1-2 week vacation. * Anyone working closely with collaborators in other time zones (I wake up every morning to a couple hundred new messages in chat.zulip.org sent by our international community members). * Any leader who spends a lot of time in meetings and wants to focus on the meeting and then batch-process communications afterwards. * Any engineer who wants to be able to spend a whole or half day focusing on a really difficult problem and catch up on conversations afterwards. * Anyone who's a part-time participant in an open community, whether they just check it once a day, one a week, or once a month. A user in this situation really wants to skim everything that happened and find what's interesting to them, not read the last few hours' traffic, which is what the Slack/Discord/Teams model forces you to do.
The same technique core works for all of these cases: pick your favorite streams and read them with `n` as I described above, then perhaps browse the list of topics in several more and click into just the topics that interest you and then mark the rest (if any) as read.
All IRC-inspired chat tools are a really rough experience for part-time participants -- they just don't have a way to let you prioritize reading interesting conversations. We discuss this issue at length and its consequences for inclusivity of the communities that use them in https://zulip.com/for/open-source/. (It's framed around inclusivity in open source, but the Slack channel model also can exclude leaders who spend most of their time in meetings)
(As a sidenote, being able to do this is why Zulip pushes users to have every conversation in a topic, rather than "threading" being a side feature used for 10% messages like some other tools do.)
Essentially everyone has miniature versions of the catch-up problem:
* Fulltime employees coming back from a normal 1-2 week vacation. * Anyone working closely with collaborators in other time zones (I wake up every morning to a couple hundred new messages in chat.zulip.org sent by our international community members). * Any leader who spends a lot of time in meetings and wants to focus on the meeting and then batch-process communications afterwards. * Any engineer who wants to be able to spend a whole or half day focusing on a really difficult problem and catch up on conversations afterwards. * Anyone who's a part-time participant in an open community, whether they just check it once a day, one a week, or once a month. A user in this situation really wants to skim everything that happened and find what's interesting to them, not read the last few hours' traffic, which is what the Slack/Discord/Teams model forces you to do.
The same technique core works for all of these cases: pick your favorite streams and read them with `n` as I described above, then perhaps browse the list of topics in several more and click into just the topics that interest you and then mark the rest (if any) as read.
All IRC-inspired chat tools are a really rough experience for part-time participants -- they just don't have a way to let you prioritize reading interesting conversations. We discuss this issue at length and its consequences for inclusivity of the communities that use them in https://zulip.com/for/open-source/. (It's framed around inclusivity in open source, but the Slack channel model also can exclude leaders who spend most of their time in meetings)
(As a sidenote, being able to do this is why Zulip pushes users to have every conversation in a topic, rather than "threading" being a side feature used for 10% messages like some other tools do.)
I don't think anyone should be expected to do that but if I wanted to read everything it would be a huge pain to do so in Slack. It is nice to have it as a realistic option.
Congrats zulip team! A very inspiring open source product.
Hope to see more open source projects migrate to something like this. It is crazy the amount of fundamental open source projects I see investing heavily in Slack and other paid services.
Or, worse (IMHO) when they tie themselves to Slack but don't pay for it, thus having messages thrown into the trash
I hold out high hopes that eventually Zulip will gain enough mental marketshare that folks will switch, since Zulip offers free hosting for open source projects, unlike ~~Slack~~ Salesforce with their bazilliontrillion dollars that they can't afford to spend to "sponsor" workspaces
I hold out high hopes that eventually Zulip will gain enough mental marketshare that folks will switch, since Zulip offers free hosting for open source projects, unlike ~~Slack~~ Salesforce with their bazilliontrillion dollars that they can't afford to spend to "sponsor" workspaces
A project I work on uses free slack and once a month exports the chat and saves them on github, ensuring the conversations are maintained in case we need to go back and review any critical decisions.
We do this and see it as a benefit. If something is important enough not to take out of a chat, is it really that important? I have been hesitating paying for Slack because I feel the usage patterns of Slack will change if we do. I think power users of Slack tend to use email less, and that's precisely what I don't want. I want to continue using e-mail for more important things and keep chat as a non critical service.
Wow I didn’t even know this project existed, and you’re telling me it’s FOSS?!
And they tag issues with labels like "good first project". It's very welcoming.
Apart from the threading model, I love Zulip for its openness.
It's quite sad Slack and Discord are often the first choice for open communities. They are siloed and unless you are deliberately searching in a specific workspace, you'll never run into the information in a search engine.
In comparison, Zulip:
- provides HTML export functionality https://github.com/zulip/zulip-archive#zulip-html-archive (example https://leanprover-community.github.io/archive )
- URLs are nice and encode meaning (e.g. https://memex.zulipchat.com/#narrow/stream/279601-hpi/topic/...) ... compare with Slack/Discord meaningless character sequences
- I'm excited about https://github.com/zulip/zulip/issues/4817 , which would allow viewing workspaces in 'guest' mode, without registering at all
In comparison, Zulip:
- provides HTML export functionality https://github.com/zulip/zulip-archive#zulip-html-archive (example https://leanprover-community.github.io/archive )
- URLs are nice and encode meaning (e.g. https://memex.zulipchat.com/#narrow/stream/279601-hpi/topic/...) ... compare with Slack/Discord meaningless character sequences
- I'm excited about https://github.com/zulip/zulip/issues/4817 , which would allow viewing workspaces in 'guest' mode, without registering at all
Zulip is amazing. I'm of the opinion that Slack is actively bad for work, because it encourages ephemeral, disjointed chats that you can't easily find again later.
Zulip is fast, light, and is a much more natural way to chat. The "river" of messages that you can zoom in and out of is just fantastic.
Zulip is fast, light, and is a much more natural way to chat. The "river" of messages that you can zoom in and out of is just fantastic.
Start treating it as async as possible, and the situation will improve. If team members get the impression you will always respond immediately, it will lead to a lot of wasted time and lack of concentration.
The thing is Slack's UX is geared against that. We can treat it as async, but the moment someone sends a second message about the same topic to the room, you're done, the conversation starts diverging.
It's also dog-slow, I have to wait for it all the time. Editing a message is an exercise in futility.
It's also dog-slow, I have to wait for it all the time. Editing a message is an exercise in futility.
I recently had to take screenshots of some 2 Year old messages in Telegram, WhatsApp and MS Teams.
In Telegram it took 3 minutes to scroll through thousands of messages and load all that data, in What's app it took 25 minutes, and in Teams I never succeeded
This is on an 8-core machine with a gigabit connection in 2021.
This is on an 8-core machine with a gigabit connection in 2021.
I'm not quite sure I understand why you would need to scroll for 25 minutes to find an old message in WhatsApp when search is available.
My first guess would be because what you're looking for isn't tagged with unique keywords (maybe just a vague idea of a date), or because pulling up a single message may not pull in it's context "grep -A/B/C" style.
I needed evidence that 2 years ago I was in touch with that person - what was sent didnt matter, nor did i remember contents of the message at all.
If what's app was not crap you could search by date, but I had to scroll.
If what's app was not crap you could search by date, but I had to scroll.
Ok that makes sense - I think the best solution in that case is to try to think of a word that you may have used around that time and search for that - then if you get the right year you can at least scroll from there.
Even so, I think WhatsApp's scroll is pretty fast especially compared to Teams. Teams only seems to be able to store 1 page worth of content in memory at any one time which makes scrolling for anything even an hour back excruciating.
Even so, I think WhatsApp's scroll is pretty fast especially compared to Teams. Teams only seems to be able to store 1 page worth of content in memory at any one time which makes scrolling for anything even an hour back excruciating.
You scroll whatsapp for a bit, and then it takes 30s to load messages. Telegram scroll is Instant, and trully endless, like a native app loading text should be
You'd think they would use the scroll bar like text editors do on huge documents. Just jump back to that point and keep +/- several screens rather than the entire freaking buffer. I wrote that for a basic text editor that I wrote for fun and it wasn't actually hard and would open gigabyte size documents almost instantly because I was only ever loading about a megabyte of info rather than the whole stinking file.
On my 2017 Xeon workstation and in Telegram, I can just press the Find shortcut, type a keyword and get results from back in 2015 in a manner of 1-2 seconds. It's amazing.
On my 6 year old mobile phone, I can do the same thing in Signal. Takes seconds to find arbitrary strings in years long very active conversations.
Honestly, I've no idea how we can accept bad performance in Teams and Slack. I can grep hundreds of megabytes of text in seconds on a raspberry pi. You have to actively try to make your software shitty to not be able to do that on a modern desktop.
Honestly, I've no idea how we can accept bad performance in Teams and Slack. I can grep hundreds of megabytes of text in seconds on a raspberry pi. You have to actively try to make your software shitty to not be able to do that on a modern desktop.
I am with you but I don't think anybody deliberately makes software shitty per se. It's more like "not my damned problem" and everybody picks a framework or a library for basic stuff and piles them on top of one another.
Almost like software should actually work
Of course. That's what I was saying. It boggles my mind how something that basic is so hard in other apps.
Not sure what you mean about Slack encouraging disjointed chats. It supports threading too and people use it almost all the time at my work.
I agree it is hard to find things again, but that's mostly because Slack's search is pretty bad, not because of any inherent properties. It's no easier to find old emails or old IRC messages or even wiki pages.
I agree it is hard to find things again, but that's mostly because Slack's search is pretty bad, not because of any inherent properties. It's no easier to find old emails or old IRC messages or even wiki pages.
A lot of people don't get threading. I'm in a small but active channel for our work team. It's roughly 15 people in a large company so it works well for us to engage and share. The problem is two others thread correctly, the rest just SPAM the main thread and when they do get the inkling to thread a reply it's often a new divergent thread off of a small conversation that someone threaded out earlier to be polite to the main.
But the worst... The worst offender on our team thinks all of their replies must be seen by everyone. So they use the "Also send to #mainthread..." for every message they send. It's almost as if training on async chat is required for some as there's a total disregard for etiquette from some.
But the worst... The worst offender on our team thinks all of their replies must be seen by everyone. So they use the "Also send to #mainthread..." for every message they send. It's almost as if training on async chat is required for some as there's a total disregard for etiquette from some.
You realize all this thread etiquette you say your teammate doesn't "get" are preferences you have that you've built up?
The problem is Slack, not your coworker. Slack's threads are conversation killers. Your coworker doesn't want to get siloed into a discussion in a thread with only the people who saw the first message, but Slack encourages that.
Sorry you're mad. Zulip does solve this problem one way.
The problem is Slack, not your coworker. Slack's threads are conversation killers. Your coworker doesn't want to get siloed into a discussion in a thread with only the people who saw the first message, but Slack encourages that.
Sorry you're mad. Zulip does solve this problem one way.
If there's a thread that someone needs to be in our team is very inclusive. We just @ them into it and it's not an issue.
I'm not mad. And there is an etiquette. I'm not blaming Slack - if you use it with some constructs in mind for how to keep conversations succinct and in their own places for others to easily find and use later - it works out better for all involved. There is value in using a tool in an efficient and repeatable manner that benefits all. This isn't a matter of being right or wrong. There are values in a user base being consistent in how they use a, mostly, unstructured tool - especially in the case of this example.
Unfortunately abusing a feature that's meant for other use cases and is not there to always be used ("Also send to #...") can be used incorrectly, and in this case it is. Everyone who needs to be in the thread is already there. It's just broadcasting to everyone who doesn't need to be the statement they've made.
I don't actually believe Zulip solves this problem, but it does look interesting for a number of other reasons.
I'm not mad. And there is an etiquette. I'm not blaming Slack - if you use it with some constructs in mind for how to keep conversations succinct and in their own places for others to easily find and use later - it works out better for all involved. There is value in using a tool in an efficient and repeatable manner that benefits all. This isn't a matter of being right or wrong. There are values in a user base being consistent in how they use a, mostly, unstructured tool - especially in the case of this example.
Unfortunately abusing a feature that's meant for other use cases and is not there to always be used ("Also send to #...") can be used incorrectly, and in this case it is. Everyone who needs to be in the thread is already there. It's just broadcasting to everyone who doesn't need to be the statement they've made.
I don't actually believe Zulip solves this problem, but it does look interesting for a number of other reasons.
Yeah I think that if your team doesn't understand threading, Zulip will be even worse. Zulip's threading model takes many people a few hours to get accustomed to, even if those people are comfortable with threading in other clients.
You just have to tell them. It might feel rude but you can do it nicely. Our work has a :please_use_threads: emoji (a needle and thread) which is a nice polite hint.
Gmail search is pretty great.
I don't concur. If there is - and it's extremely ironic - a badly implemented feature in GMail, that's manual searching and especially filtering.
Please tell me what I'm doing wrong because it works just fine for me?
True, but I can't use Gmail at work so that doesn't really help.
> you can't easily find again later.
I sometimes have problems to find the new message I know I just got a few seconds ago due to how "non read messages marker" and "threads" (or however they call it) interact.
I never understood why people where so hyped about slack while there most times where better alternatives.
And let's not even get started about slacks audio/video chat function which is by far the worst I had used in recent times. Even the unliked MS Teams is miles better for voice or video chat. (Just to be clear I never used MS Teams for anything but voice/video chat.)
I sometimes have problems to find the new message I know I just got a few seconds ago due to how "non read messages marker" and "threads" (or however they call it) interact.
I never understood why people where so hyped about slack while there most times where better alternatives.
And let's not even get started about slacks audio/video chat function which is by far the worst I had used in recent times. Even the unliked MS Teams is miles better for voice or video chat. (Just to be clear I never used MS Teams for anything but voice/video chat.)
I don't like Slack but Discord is a great piece of engineering. They hit all the right spots for many types of communities. Personally for searching I actually with people used chat groups less and opened stackoverflow questions more. I hate having to search through unstructured chat to find if someone asked my question previously or if no one answers your question right away it gets buried under new questions. What zulip needs to compete against Discord is voice chats. I feel like many communities feel the need to exist on voice and chat channels at the same time and not having that forces people to have 2 disconnected services
I think once Zulip gets a "guest mode", it will be a huge boon in its adoption for OSS communities. I love Zulip!
> I think once Zulip gets a "guest mode", it will be a huge boon in its adoption for OSS communities
Agreed!
To clarify the terminology, "guests" in Zulip (and other team chat products, e.g. Slack) generally refers to users with an account but with limited access. https://zulip.com/help/roles-and-permissions has more detail on that.
We've been tentatively planning to use the term "web-public streams" for streams that an open community has configured to be accessible without creating a Zulip account. The project is quite far along; the latest PR is here:
https://github.com/zulip/zulip/pull/16728
(The PR looks stale, but that's only because we paused integrating it to focus on finishing 4.0; I would be sad if we don't have it at least in beta this summer.)
Agreed!
To clarify the terminology, "guests" in Zulip (and other team chat products, e.g. Slack) generally refers to users with an account but with limited access. https://zulip.com/help/roles-and-permissions has more detail on that.
We've been tentatively planning to use the term "web-public streams" for streams that an open community has configured to be accessible without creating a Zulip account. The project is quite far along; the latest PR is here:
https://github.com/zulip/zulip/pull/16728
(The PR looks stale, but that's only because we paused integrating it to focus on finishing 4.0; I would be sad if we don't have it at least in beta this summer.)
[deleted]
To be fair, the Discord URIs are passed around in chat, etc. They're not that opaque, for a guild message it's just serverid/channelid/messageid. The numbers are snowflakes.
>It's quite sad Slack and Discord are often the first choice for open communities.
Slack is particularly bad as you need to make a new account for each instance (i.e. project). And you need to log in to each instance separately on each device where you have Slack.
Slack is particularly bad as you need to make a new account for each instance (i.e. project). And you need to log in to each instance separately on each device where you have Slack.
This is why I struggle to understand how Slack has been adopted so broadly for building online communities.
The need to have separate accounts per instance is such a hassle. I spent twenty minutes yesterday trying to find which account I used to sign in to a dev-related Slack on a new laptop that had yet to login.
The need to have separate accounts per instance is such a hassle. I spent twenty minutes yesterday trying to find which account I used to sign in to a dev-related Slack on a new laptop that had yet to login.
Conversely, I’m on several slacks, and I’ve only ever used the same account on all of them. One slack app and one slack account works for all of them.
I do hate the way that Discord forces me to use the same account and same profile on all the discord servers I connect to through the client. I could connect to different ones with different accounts on different web browsers, but that’s a royal pain.
I guess I care more about the different communities I connect to through Discord, and I want to have more unique profiles for each of them, whereas just the one profile works for all the slacks that I am connected to.
I do hate the way that Discord forces me to use the same account and same profile on all the discord servers I connect to through the client. I could connect to different ones with different accounts on different web browsers, but that’s a royal pain.
I guess I care more about the different communities I connect to through Discord, and I want to have more unique profiles for each of them, whereas just the one profile works for all the slacks that I am connected to.
> Conversely, I’m on several slacks, and I’ve only ever used the same account on all of them. One slack app and one slack account works for all of them.
How? Each time I join a slack, e.g. haproxy, i need to make a new slack account tied to my email address for that slack instance. How do you make a single slack account to be used everywhere?
How? Each time I join a slack, e.g. haproxy, i need to make a new slack account tied to my email address for that slack instance. How do you make a single slack account to be used everywhere?
Zulip's an awesome F/OSS chat option, consider contributing to it, even if it's only translations in your native language.
The project seems healthy, and is growing at a good pace and adding more features and people aren't burning out, seems to be doing a lot of things right as far as F/OSS project management goes. Tim is also a joy to interact with.
The project seems healthy, and is growing at a good pace and adding more features and people aren't burning out, seems to be doing a lot of things right as far as F/OSS project management goes. Tim is also a joy to interact with.
I was skeptical about Zulip when I first tried it. What is it supposed to be? A chat? A forum? Why is the UI so ugly?
But after using it a while I now really dislike Slack et al, both in professional teams and for open source communities.
Zulip can give you the best of both worlds. It's a regular chat. But the threading model also encourages long-form, more forum or email like discussions.
Threads are easily discoverable and it's trivial to catch up on all the relevant discussions that you missed, while skipping everything that doesn't concern you.
You can still have some regular chat channels for typical ephemeral discussion that no-one is expected to read. It's really a great tool.
The only downside is the very subpar UX when compared to Discord or even Slack.
But after using it a while I now really dislike Slack et al, both in professional teams and for open source communities.
Zulip can give you the best of both worlds. It's a regular chat. But the threading model also encourages long-form, more forum or email like discussions.
Threads are easily discoverable and it's trivial to catch up on all the relevant discussions that you missed, while skipping everything that doesn't concern you.
You can still have some regular chat channels for typical ephemeral discussion that no-one is expected to read. It's really a great tool.
The only downside is the very subpar UX when compared to Discord or even Slack.
I have heard a few people complain about the UI but I like it, and it seems comparable to other chat apps. What about Slack/Discord is better? Genuinely trying to understand.
As for UX, I think Zulip has a strong advantage w/r/t the threading model, which you seem to be saying as well.
As for UX, I think Zulip has a strong advantage w/r/t the threading model, which you seem to be saying as well.
I had created this extension for my personal use, that "modernizes" the Zulip UI. Most people seem to have a better UI experience using it from the feedback I have received. Feel free to try it out .
https://addons.mozilla.org/en-US/firefox/addon/prettier-zuli...
I have heard complaints where I work that less-technical foks find the UI unpleasant/confusing. I think it is due to a combination of the keyboard shortcuts being front-and-center and the threading model seeming "complex" (really, just logically structured)
I'm not sure there is a strong/good argument against it, though. e.g. word processors are "more complex" than text files for sure, but people have learned the benefits of those.
I think the education / user-onboarding flow could be improved perhaps.
I'm not sure there is a strong/good argument against it, though. e.g. word processors are "more complex" than text files for sure, but people have learned the benefits of those.
I think the education / user-onboarding flow could be improved perhaps.
The usual complaints I get (as an admin of an instance) are:
1. "Hard to search"/"Can't find anything".
2. Off-topic responses because people post in whatever the most recent thread they used happens to be (results in (1)).
I like it, though, due to having some similarities to a forum.
Past experience suggests that many folks who are unhappy with Zulip's visuals are satisfied if they do the following things:
* Using the night theme, which some folks strongly prefer to day theme.
* Zooming to 110%, which makes Zulip's font size similar to Slack and its clones.
With any luck, this summer we'll migrate our default font size to match other modern webapps, ideally with a "Dense mode" that preserves the current size for folks who want to fit more content on their screen.
I've thought about changing the default theme to the day theme, but it seems a little sad to remove our current defaut (of automatically detecting the browser configuration via `prefers-color-scheme`).
* Using the night theme, which some folks strongly prefer to day theme.
* Zooming to 110%, which makes Zulip's font size similar to Slack and its clones.
With any luck, this summer we'll migrate our default font size to match other modern webapps, ideally with a "Dense mode" that preserves the current size for folks who want to fit more content on their screen.
I've thought about changing the default theme to the day theme, but it seems a little sad to remove our current defaut (of automatically detecting the browser configuration via `prefers-color-scheme`).
I tried Zulip a few years ago and found it too "ugly" to recommend to non-technical peers (I also didn't grok the threads model).
I checked the website now to see if I'd like the night mode better, and I can't find any screenshots with it!
If people tend to vastly prefer zulips UI with the settings you mention, your product adoption will probably be much higher if your website screenshots show the dark mode with 110% zoom.
While it'd be nice to improve the defaults, I know that can be disruptive - the quickest quickfix would be to mention those settings in the installation instructions.
Failing the change mentioned above, it would at least be nice to include some screenshots on the help article about turning on night mode (ideally with some good alt text so google images picks it up).
Disclaimer that I only looked at the top two DDG results for "Zulip night mode"
I checked the website now to see if I'd like the night mode better, and I can't find any screenshots with it!
If people tend to vastly prefer zulips UI with the settings you mention, your product adoption will probably be much higher if your website screenshots show the dark mode with 110% zoom.
While it'd be nice to improve the defaults, I know that can be disruptive - the quickest quickfix would be to mention those settings in the installation instructions.
Failing the change mentioned above, it would at least be nice to include some screenshots on the help article about turning on night mode (ideally with some good alt text so google images picks it up).
Disclaimer that I only looked at the top two DDG results for "Zulip night mode"
I strongly prefer the dark theme. My 2 cents is that using that as a default will be a good idea.
FWIW I find the browser configuration check to be flakey in other contexts. Especially with non-technical people, who may never know to toggle dark mode.
FWIW I find the browser configuration check to be flakey in other contexts. Especially with non-technical people, who may never know to toggle dark mode.
I STRONGLY recommend optimizing for the average non technical user and mass adoption. Basically, copy Slack’s visual design as much as you can while retaining what makes Zulip great.
Branding and visual design matters. Far more than most folks think.
Branding and visual design matters. Far more than most folks think.
> Basically, copy Slack’s visual design as much as you can
There are a ton of unpleasant / user hostile features of Slack’s visual design. It is full of stuff blinking, flashing, popping in and out of view, etc. Trying to chat feels like having a conversation in the middle of a casino.
So please don’t do this.
There are a ton of unpleasant / user hostile features of Slack’s visual design. It is full of stuff blinking, flashing, popping in and out of view, etc. Trying to chat feels like having a conversation in the middle of a casino.
So please don’t do this.
Please do this - I deployed slack in a business environment - staff love it. Trying to get them to use alternatives with what they call "weird" interfaces is a no go.
Slack nailed it - and adoption numbers are proving that out over and over.
I got complaints even on teams font size being too small! Don't underestimate these issues.
Slack nailed it - and adoption numbers are proving that out over and over.
I got complaints even on teams font size being too small! Don't underestimate these issues.
[deleted]
Really? I honestly have no idea what you're referring too, as someone that uses slack at a full time remote job.
Nothing blinks or flashes as far as I'm aware. Just the UI changing when other people interact with the server. Like emoji reactions pop in if someone adds one. Or left side bar highlighting things if there's new messages in them, etc.
Things pretty much any other chat-like application does.
Nothing blinks or flashes as far as I'm aware. Just the UI changing when other people interact with the server. Like emoji reactions pop in if someone adds one. Or left side bar highlighting things if there's new messages in them, etc.
Things pretty much any other chat-like application does.
And yet the average non tech user took to it like a fish to water compared to all alternatives that came before it.
> I STRONGLY recommend optimizing for the average non technical user and mass adoption.
I agree with that, and I hope my comment above didn't mean to sound dismissive of concerns about visual design!
Visual work to mean these workarounds are not required is one of our main priorities for the next few months, and I mentioned the above mainly because many folks have found them helpful when using the Zulip that exists today.
(As a sidenote, we have an open position for a designer).
I agree with that, and I hope my comment above didn't mean to sound dismissive of concerns about visual design!
Visual work to mean these workarounds are not required is one of our main priorities for the next few months, and I mentioned the above mainly because many folks have found them helpful when using the Zulip that exists today.
(As a sidenote, we have an open position for a designer).
Automatically detecting prefers-color-scheme is the right thing to do in general - maybe the day theme needs some improvements (based purely on this thread).
I think zulipchat has a usable UI but it's not as visually inviting as slack. Less brightness, colors, emoji and the like. It might actually have support for this stuff now as I've not tested the latest version. I'm not saying this stuff should be added but that's my takeaway on the differences.
Funny that you enumerated all the crap that I absolutely detest in slack. I think there are really two populations, those who should be considered definitely lost by having had their brain washed by UI vendors ruining user experience, and those who are still trying to get their work done through this ocean of horrors.
Zulip is uglier in every aspect, like colors, icons, spacing and content organization. They should hire or recruit an UI designer.
I think you mean "UI", as in "visuals", because the UX is the best, bar none.
The thing that puts me off is that you have to choose a subject for every message. Bit of a pain. And I can't see how it's threading is significantly better than Slack's.
Previously at EI2030, we were using Discord, and it wasn't easy to find and keep track of information as we were growing. We've transitioned to Zulip and couldn't be happier.
The article from monadical describes it best: "...[Zulip] creates an organized repository of knowledge as a side effect"
Thank you to the Zulip team!
https://monadical.com/posts/how-to-make-remote-work-part-two...
https://ei2030.zulipchat.com/
The article from monadical describes it best: "...[Zulip] creates an organized repository of knowledge as a side effect"
Thank you to the Zulip team!
https://monadical.com/posts/how-to-make-remote-work-part-two...
https://ei2030.zulipchat.com/
Sort of off topic, but does anyone know why Dropbox acquired Zulip and preceded to do nothing with it?
It seems to be an acquihire and they didn't care for the product. This happens fairly often in general.
Glad they at least got to opensource it instead of just killing it.
Glad they at least got to opensource it instead of just killing it.
I can’t speak to decision making, but I can add one viewpoint.
My understanding is that Zulip was called Chime internally.
Management pushed teams to use the tool, and it was tried but the interface was not polished.
Slack was already out and despite how it is seen today, slack far more appealing.
Slack’s interface, single sign-on and mobile app availability made it hard for Chime to compete.
My understanding is that Zulip was called Chime internally.
Management pushed teams to use the tool, and it was tried but the interface was not polished.
Slack was already out and despite how it is seen today, slack far more appealing.
Slack’s interface, single sign-on and mobile app availability made it hard for Chime to compete.
> My understanding is that Zulip was called Chime internally.
I don't think this is accurate. At least, I'm aware of a chat project called Chime at Dropbox circa 2015 that was not based on Zulip and at least at the time did not materially involve anyone from the original Zulip team.
(I suppose some of those things could have changed since I last heard anything on the topic).
I don't think this is accurate. At least, I'm aware of a chat project called Chime at Dropbox circa 2015 that was not based on Zulip and at least at the time did not materially involve anyone from the original Zulip team.
(I suppose some of those things could have changed since I last heard anything on the topic).
Okay, I was not there, so if you know you know.
It seems additionally strange that after buying Zulip in March 2014 a wholly separate chat application would be in use. But stranger things happen.
It seems additionally strange that after buying Zulip in March 2014 a wholly separate chat application would be in use. But stranger things happen.
Looks good but how does it compare to matrix/element?
The thread feature is fucking awesome. I hope matrix implements something similar.
I have very little experience with Zulip, so take this with a grain of salt. Just like Matrix, Zulip is open source and can be self-hosted. They both target instant-messaging use cases.
Zulip has a far more advanced threading model than Matrix. Currently, Matrix only has basic replies in the spec. In practice, everything in a Matrix room is in a single thread. It definitely makes it hard to follow conversations that are long-lived or in busy rooms or both.
Matrix is federated and Zulip isn't. You can run your own Matrix server and communicate with all the other Matrix servers that already exist. Rooms live on multiple servers and are resilient to the failure of any participating servers as long as one remains.
Matrix is far more general than Zulip. It acts as a store for arbitrary, eventually-consistent, ordered JSON data. Most of the time this is used to create an instant messaging service, but it can be used for much more.
Zulip subjectively has a nicer default client than Matrix (Element). Zulip's is special-built to handle its unique threading model.
It's also worth noting that Matrix is adding support for arbitrary threading [0]. I'm really looking forward to this. It should allow us to build a Zulip clone fully in Matrix with all of the benefits that come with the Matrix ecosystem.
[0]: https://github.com/matrix-org/matrix-doc/blob/kegan/msc/thre...
Zulip has a far more advanced threading model than Matrix. Currently, Matrix only has basic replies in the spec. In practice, everything in a Matrix room is in a single thread. It definitely makes it hard to follow conversations that are long-lived or in busy rooms or both.
Matrix is federated and Zulip isn't. You can run your own Matrix server and communicate with all the other Matrix servers that already exist. Rooms live on multiple servers and are resilient to the failure of any participating servers as long as one remains.
Matrix is far more general than Zulip. It acts as a store for arbitrary, eventually-consistent, ordered JSON data. Most of the time this is used to create an instant messaging service, but it can be used for much more.
Zulip subjectively has a nicer default client than Matrix (Element). Zulip's is special-built to handle its unique threading model.
It's also worth noting that Matrix is adding support for arbitrary threading [0]. I'm really looking forward to this. It should allow us to build a Zulip clone fully in Matrix with all of the benefits that come with the Matrix ecosystem.
[0]: https://github.com/matrix-org/matrix-doc/blob/kegan/msc/thre...
I wish the Matrix/Element folks the very best of luck, because they're pretty aligned with Zulip values-wise.
That said, I don't think you should expect a Zulip-style threading user experience in Element anytime soon. Regardless of how the Matrix protocol for federation between servers is extended, providing the "Zulip user experience" would likely require a major overhaul of both their client/server protocol for Element and their client user experience. (Also, the proposal you link is for HN-style threading, not Zulip-style topics).
I don't understand Element's internals, but my basis for this claim is a huge portion of all technical and design work we do on Zulip wouldn't be necessary or would be much simpler if Zulip didn't have topics (E.g. the architectural decision criticized in https://news.ycombinator.com/item?id=27150492 is a good example). See https://news.ycombinator.com/item?id=27150196 for a few more examples. I imagine Element will only invest in all of that work that if they believe it's important to their business.
As an outside observer, Element's business focus seems to be on competing with WhatsApp/Messenger/Signal/Telegram/SMS, not Slack, so while I'd love to see Matrix/Element borrow Zulip's topics model, you probably shouldn't hold your breath.
That said, I don't think you should expect a Zulip-style threading user experience in Element anytime soon. Regardless of how the Matrix protocol for federation between servers is extended, providing the "Zulip user experience" would likely require a major overhaul of both their client/server protocol for Element and their client user experience. (Also, the proposal you link is for HN-style threading, not Zulip-style topics).
I don't understand Element's internals, but my basis for this claim is a huge portion of all technical and design work we do on Zulip wouldn't be necessary or would be much simpler if Zulip didn't have topics (E.g. the architectural decision criticized in https://news.ycombinator.com/item?id=27150492 is a good example). See https://news.ycombinator.com/item?id=27150196 for a few more examples. I imagine Element will only invest in all of that work that if they believe it's important to their business.
As an outside observer, Element's business focus seems to be on competing with WhatsApp/Messenger/Signal/Telegram/SMS, not Slack, so while I'd love to see Matrix/Element borrow Zulip's topics model, you probably shouldn't hold your breath.
Thanks for pointing out that the upcoming Matrix threading model I linked to isn't the same as what Zulip has. I wasn't thinking about Zulip's model correctly.
After doing some research, I think you're right that the proposal won't immediately enable Zulip-style threading. Though, it seems like a small change on top of the linked MSC (Matrix Spec Change) proposal would enable Zulip-style threading.
If Matrix had an event type that created a "topic", that's all you would need. The linked MSC is very general and allows events to reference arbitrary parent and child events, and allows updating those parent and child relationships. If the parent is some kind of "m.topic" declaration event, maybe that would be enough.
It's also entirely possible that Zulip style threading doesn't even require that new event and I'm just not familiar enough with Matrix to see how.
---
Your points about how advanced the Zulip client is, though, are very true. It will take a ton of work for Element or some other Matrix client to catch up. You guys really built something impressive there.
I look forward to seeing what Zulip comes out with in terms of federation. It's a tough problem.
After doing some research, I think you're right that the proposal won't immediately enable Zulip-style threading. Though, it seems like a small change on top of the linked MSC (Matrix Spec Change) proposal would enable Zulip-style threading.
If Matrix had an event type that created a "topic", that's all you would need. The linked MSC is very general and allows events to reference arbitrary parent and child events, and allows updating those parent and child relationships. If the parent is some kind of "m.topic" declaration event, maybe that would be enough.
It's also entirely possible that Zulip style threading doesn't even require that new event and I'm just not familiar enough with Matrix to see how.
---
Your points about how advanced the Zulip client is, though, are very true. It will take a ton of work for Element or some other Matrix client to catch up. You guys really built something impressive there.
I look forward to seeing what Zulip comes out with in terms of federation. It's a tough problem.
On the federation front, if your goal is to connect different chat services running different chat protocols, that's been possible for years with tools like Matterbridge (https://github.com/42wim/matterbridge). Zulip also has direct bridge integrations with IRC and a handful of other protocols, e.g. https://zulip.com/integrations/doc/irc.
These integrations are a bit ugly and certainly not the ideal design, but they work and help a lot of communities that are 90% on Zulip but still want an IRC presence for whatever reason. (A fun historical note: Zulip's had a really nice puppet-powered bridge with Zephyr since 2012, because that was how we got enough usage during its early development to design the product and its data model with real users).
Longer term, we're planning to build a native Zulip federation feature. For us the technical strategy has been to first make a Zulip world-class user experience, and do native federation later.
Our strategy is motivated by XMPP, which like Matrix is extremely general (E.g. I talked to people who used XMPP as message bus for their backend infrastructure 10 years ago). XMPP is dying as a chat protocol because nobody can build a modern world-class chat application using it as the client/server protocol.
E.g. multiple people who'd worked as engineers on now-dead chat products complained that because their mobile apps talked XMPP to their server, it was impossible for them to make the apps start quickly in medium-size organizations, because of all the round-trips required.
In contrast, Zulip's client/server protocol both on web and mobile returns all metadata in a single HTTP request: https://zulip.com/api/register-queue, and then after that, another to fetch whatever messages you're going to look at.
These integrations are a bit ugly and certainly not the ideal design, but they work and help a lot of communities that are 90% on Zulip but still want an IRC presence for whatever reason. (A fun historical note: Zulip's had a really nice puppet-powered bridge with Zephyr since 2012, because that was how we got enough usage during its early development to design the product and its data model with real users).
Longer term, we're planning to build a native Zulip federation feature. For us the technical strategy has been to first make a Zulip world-class user experience, and do native federation later.
Our strategy is motivated by XMPP, which like Matrix is extremely general (E.g. I talked to people who used XMPP as message bus for their backend infrastructure 10 years ago). XMPP is dying as a chat protocol because nobody can build a modern world-class chat application using it as the client/server protocol.
E.g. multiple people who'd worked as engineers on now-dead chat products complained that because their mobile apps talked XMPP to their server, it was impossible for them to make the apps start quickly in medium-size organizations, because of all the round-trips required.
In contrast, Zulip's client/server protocol both on web and mobile returns all metadata in a single HTTP request: https://zulip.com/api/register-queue, and then after that, another to fetch whatever messages you're going to look at.
As someone who worked on an XMPP web client that set up a whole session in a single HTTP request and response, I can say it's definitely possible to do this.
XMPP also has optimisations so you can resume a session across network disconnects etc. so that session initialization is typically limited to app start.
A more fundamental issue for many of these apps is that XMPP group chats were very presence-focused, and quite chatty (you need to join and sync every channel every new session). People have worked around that in various ways in the past. These days we have the newer 'MIX' standard for group chats which is not per session and far cheaper for many/large groups.
XMPP has evolved, and continues to evolve. But I fear that people inventing their own chat protocols is a problem that can never be fully solved.
XMPP also has optimisations so you can resume a session across network disconnects etc. so that session initialization is typically limited to app start.
A more fundamental issue for many of these apps is that XMPP group chats were very presence-focused, and quite chatty (you need to join and sync every channel every new session). People have worked around that in various ways in the past. These days we have the newer 'MIX' standard for group chats which is not per session and far cheaper for many/large groups.
XMPP has evolved, and continues to evolve. But I fear that people inventing their own chat protocols is a problem that can never be fully solved.
> You can run your own Matrix server and communicate with all the other Matrix servers that already exist.
What's the benefit of this? Seems like a very niche feature.
> Most of the time this is used to create an instant messaging service, but it can be used for much more.
What other use could there be?
I'd want a software that does one thing well because to this day there isn't even a chat solution that rules all the others.
What's the benefit of this? Seems like a very niche feature.
> Most of the time this is used to create an instant messaging service, but it can be used for much more.
What other use could there be?
I'd want a software that does one thing well because to this day there isn't even a chat solution that rules all the others.
> What's the benefit of this? Seems like a very niche feature.
Cross organizational communication, e.g. across ministries (like France realized it with 60 Matrix servers), across different offices of companies, across multiple companies, across universities (which was e.g. important for TU Dresden).
In principle it is the same with Email.
> What other use could there be?
> I'd want a software that does one thing well because to this day there isn't even a chat solution that rules all the others.
Matrix is a protocol, not a software. Specifically it is a communication protocol. So anyone can create software that needs communication which benefits from properties that Matrix provides, can use it independently of the software you are using to chat.
Cross organizational communication, e.g. across ministries (like France realized it with 60 Matrix servers), across different offices of companies, across multiple companies, across universities (which was e.g. important for TU Dresden).
In principle it is the same with Email.
> What other use could there be?
> I'd want a software that does one thing well because to this day there isn't even a chat solution that rules all the others.
Matrix is a protocol, not a software. Specifically it is a communication protocol. So anyone can create software that needs communication which benefits from properties that Matrix provides, can use it independently of the software you are using to chat.
If you can only talk to other people on your own server, then the application is limited to just team chat.
Matrix clients have the potential to be much more. You can use the same account for various team chats and still use it like a messaging app for your friends and arbitrary personal groups.
Maybe most importantly, federation provides resilience against bad server operators. If Signal had allowed federation, it wouldn't have been a big deal to ditch its servers when they introduced a sketchy cryptocurrency onto the platform. Because they don't allow it, everyone was locked in.
Matrix clients have the potential to be much more. You can use the same account for various team chats and still use it like a messaging app for your friends and arbitrary personal groups.
Maybe most importantly, federation provides resilience against bad server operators. If Signal had allowed federation, it wouldn't have been a big deal to ditch its servers when they introduced a sketchy cryptocurrency onto the platform. Because they don't allow it, everyone was locked in.
At FOSDEM (I believe) earlier this year it was mentioned that zulip interoperabily with Matrix is actively being worked on. Unfortunately the release announcement does not mention it, so probably not yet ready for public release?
As a regular zulip user it's a shock to me every time I have to use the element client. I have the feeling the latter is very slack-like in tis look and feel. I could be wrong on this, luckily I haven't had to use Slack for 3 years. Unfortunately with people used to Slack, it will be a shock to them to use zulip.
As a regular zulip user it's a shock to me every time I have to use the element client. I have the feeling the latter is very slack-like in tis look and feel. I could be wrong on this, luckily I haven't had to use Slack for 3 years. Unfortunately with people used to Slack, it will be a shock to them to use zulip.
Some past threads:
Zulip 3.0: Threaded Open Source Team Chat - https://news.ycombinator.com/item?id=23860338 - July 2020 (133 comments)
Zulip 2.1: open-source team chat - https://news.ycombinator.com/item?id=21779717 - Dec 2019 (1 comment)
Zulip 2.0: Open source team chat - https://news.ycombinator.com/item?id=19284321 - March 2019 (96 comments)
Zulip Server 1.9: HipChat import and much more - https://news.ycombinator.com/item?id=18400988 - Nov 2018 (123 comments)
Zulip – Open-source, threading-based Slack alternative - https://news.ycombinator.com/item?id=17622987 - July 2018 (99 comments)
Slack channels are a waste of time - https://news.ycombinator.com/item?id=17622707 - July 2018 (49 comments)
Zulip 1.8: Free software Slack alternative with email-style threading - https://news.ycombinator.com/item?id=16863675 - April 2018 (148 comments)
Zulip Server 1.6 released - https://news.ycombinator.com/item?id=14506426 - June 2017 (14 comments)
Dropbox has open-sourced Zulip - https://news.ycombinator.com/item?id=10279961 - Sept 2015 (313 comments)
Dropbox Acquires Zulip, A Stealthy Workplace Chat Solution Still In Private Beta - https://news.ycombinator.com/item?id=7419408 - March 2014 (14 comments)
Zulip 3.0: Threaded Open Source Team Chat - https://news.ycombinator.com/item?id=23860338 - July 2020 (133 comments)
Zulip 2.1: open-source team chat - https://news.ycombinator.com/item?id=21779717 - Dec 2019 (1 comment)
Zulip 2.0: Open source team chat - https://news.ycombinator.com/item?id=19284321 - March 2019 (96 comments)
Zulip Server 1.9: HipChat import and much more - https://news.ycombinator.com/item?id=18400988 - Nov 2018 (123 comments)
Zulip – Open-source, threading-based Slack alternative - https://news.ycombinator.com/item?id=17622987 - July 2018 (99 comments)
Slack channels are a waste of time - https://news.ycombinator.com/item?id=17622707 - July 2018 (49 comments)
Zulip 1.8: Free software Slack alternative with email-style threading - https://news.ycombinator.com/item?id=16863675 - April 2018 (148 comments)
Zulip Server 1.6 released - https://news.ycombinator.com/item?id=14506426 - June 2017 (14 comments)
Dropbox has open-sourced Zulip - https://news.ycombinator.com/item?id=10279961 - Sept 2015 (313 comments)
Dropbox Acquires Zulip, A Stealthy Workplace Chat Solution Still In Private Beta - https://news.ycombinator.com/item?id=7419408 - March 2014 (14 comments)
[deleted]
Whats to keep slack from just adding this feature and blowing their value prop out of the water?
Maybe a hot take here, but as someone who works for Salesforce, if the Salesforce acquisition goes through, my guess is that most of Slack's time for a while will be occupied on pushing through tight coupling to Salesforce systems in the name of "integration" rather than features users actually want.
That's not based on any sorta "secret insider information", it's just the pattern I've seen with companies they/we acquire.
That's not based on any sorta "secret insider information", it's just the pattern I've seen with companies they/we acquire.
Slack is the legacy dinosaur now. So adding a dramatic feature shift like this to a mature product will be problematic for a big old project like them. They've got "enterprise" clients to consume their focus.
As someone who is subjected to slack, I kind of hope this happens. I have my doubts they ever will though, or would be able to do it well.
When I founded Zulip, one of my stated goals was to change how the world communicates to be more efficient, just as my goal in founding Ksplice was to make rebootless updates ubiquitous.
So if Slack and all of its clones copy Zulip's model, I'd call that a success for us having changed the way people work. That said, Zulip is 100% open source under the Apache license (very rare these days), and that will remain a differentiator, as you can't self-host Slack, nor can you audit its source code or fork it to solve a problem specific to your use case. (We also have a lot of other innovative features, like native LaTeX support, customizable linkifers, etc.).
That said, topics are not something one can just copy in an existing chat app -- there's a lot more to Zulip's topic-based threading model than "a feature".
* Being able improve organization by renaming and splitting topics, move topics between streams, etc., is critical to the reading and conversation experience. This requires lot of thought about subtle technical and user experience details. (E.g. if someone renames a topic, and you were in the process of composing a reply, your compose box updates to the the new topic).
* Tracking unread counts on a per-message basis, rather than a "pointer within a channel", which is required for splitting topics to do something sane. This, in turn, requires clever data structures so that the moment the browser loads, you can see where all 35000 unread messages are. (Folks routinely have that when they come back to a busy open community after months away).
* All sort of clever performance and client-side caching things to make it feel like the browser has all your data so that clicking around feels instant.
* Dozens more things along these lines.
And those are just the engineering details. The bigger part of topics that it requires an overhaul of the whole UI. At least for us, a huge fraction of features are different than they would otherwise be because of topics (E.g. Zulip's compose box supporting sending to a different place than what you're looking at, and fading messages that weren't sent to that place to help users avoid mistakes). This sort of overhaul is hard to do, and even harder to do with a large existing userbase.
As a result, if Zulip fails, I'd be very surprised if it's because other companies copied Zulip's model so well that there was no reason to prefer Zulip's topics implementation.
Far more likely is some combination of our competition having infinite marketing dollars, inertia in organizations that don't realize how much better their working experience could be, and Microsoft's campaign to make everyone unwilling use anything other than Teams, because "we already bought Teams with our Office 365 subscription".
So if Slack and all of its clones copy Zulip's model, I'd call that a success for us having changed the way people work. That said, Zulip is 100% open source under the Apache license (very rare these days), and that will remain a differentiator, as you can't self-host Slack, nor can you audit its source code or fork it to solve a problem specific to your use case. (We also have a lot of other innovative features, like native LaTeX support, customizable linkifers, etc.).
That said, topics are not something one can just copy in an existing chat app -- there's a lot more to Zulip's topic-based threading model than "a feature".
* Being able improve organization by renaming and splitting topics, move topics between streams, etc., is critical to the reading and conversation experience. This requires lot of thought about subtle technical and user experience details. (E.g. if someone renames a topic, and you were in the process of composing a reply, your compose box updates to the the new topic).
* Tracking unread counts on a per-message basis, rather than a "pointer within a channel", which is required for splitting topics to do something sane. This, in turn, requires clever data structures so that the moment the browser loads, you can see where all 35000 unread messages are. (Folks routinely have that when they come back to a busy open community after months away).
* All sort of clever performance and client-side caching things to make it feel like the browser has all your data so that clicking around feels instant.
* Dozens more things along these lines.
And those are just the engineering details. The bigger part of topics that it requires an overhaul of the whole UI. At least for us, a huge fraction of features are different than they would otherwise be because of topics (E.g. Zulip's compose box supporting sending to a different place than what you're looking at, and fading messages that weren't sent to that place to help users avoid mistakes). This sort of overhaul is hard to do, and even harder to do with a large existing userbase.
As a result, if Zulip fails, I'd be very surprised if it's because other companies copied Zulip's model so well that there was no reason to prefer Zulip's topics implementation.
Far more likely is some combination of our competition having infinite marketing dollars, inertia in organizations that don't realize how much better their working experience could be, and Microsoft's campaign to make everyone unwilling use anything other than Teams, because "we already bought Teams with our Office 365 subscription".
I work at a tech company of about 500. We've used zulip for a few years now and are looking to switch to teams/o365. The reason is to have more integration between email, documents, chat, video meetings, and calendar. Zulip has been good to us but as we grow it's increasingly burdensome to manage a bunch of disparate open source collaboration tools.
So many thanks to you for creating Zulip, I love it to bits.
>Giphy integration.
Am I the only person who’d prefer their, potentially corporate, chat not be tracked by Facebook.
Facebook owns Giphy [0]
[0] https://techcrunch.com/2020/05/15/facebook-to-acquire-giphy-...
Am I the only person who’d prefer their, potentially corporate, chat not be tracked by Facebook.
Facebook owns Giphy [0]
[0] https://techcrunch.com/2020/05/15/facebook-to-acquire-giphy-...
Whoa FB bought Giphy? I guess I missed that in the heat of the pandemic. Goodness I wish there were fewer acquisitions.
Is Tenor still independent?
tenor was purchased by google in 2018 (https://techcrunch.com/2018/03/27/google-acquires-gif-platfo...)
(edit to add info and link)
(edit to add info and link)
Nope, you aren’t. Zulip proxies all external images in messages through the server, including those from Giphy, to stop them from being used to track you. (Also, Giphy integration can be disabled per-organization by an organization administrator.)
Side note: Signal does this as well, this is why privacy-oriented services still offer a Giphy integration.
[deleted]
Zulip has a notoriously bad db schema. For example, a single write in a 5000 member public group would result in 5000 writes to the user table.
> Zulip has a notoriously bad db schema.
Interesting, I've never heard that rumor before.
> a single write in a 5000 member public group would result in 5000 writes to the user table.
This hasn't been true since we implemented soft deactivation in 2017. You can read about the feature in our documentation here; I think it's a pretty cool design:
https://zulip.readthedocs.io/en/latest/subsystems/sending-me...
The optimization takes advantage of the fact that public groups with 10Ks of members tend to have a lot of totally inactive users, and so if you have a good way to know that only 600 of them have logged in during the last 2 weeks, your server can run like it only has 600 users.
It is true that Zulip writes a tiny UserMessage table row with (user_id, message_id, flags) for every active recipient of a message, we need to do so in order to track the unread state for all of those recipients (as well as related details, like mobile push notifications state). We need to write to that row a second time when the user reads the message.
With modern postgres and SSDs, writing 1000 rows is really cheap, and so part this is extremely fast when sending messages with 1000 online recipients, which isn't a thing real users do constantly anyway (since that's effectively an announcement, not a chat message).
Folks who are curious can read https://chat.zulip.org/#narrow/stream/3-backend/topic/send_m..., which is related optimization work we did this week that made it into this release.
(You could have a bad experience if you use remote storage that rate-limits "IOPS", though, because AWS at least used to count each row as an IOP and would use your full quota for 20s if you marked 20K messages as read with a 1000 UOP/s plan).
Interesting, I've never heard that rumor before.
> a single write in a 5000 member public group would result in 5000 writes to the user table.
This hasn't been true since we implemented soft deactivation in 2017. You can read about the feature in our documentation here; I think it's a pretty cool design:
https://zulip.readthedocs.io/en/latest/subsystems/sending-me...
The optimization takes advantage of the fact that public groups with 10Ks of members tend to have a lot of totally inactive users, and so if you have a good way to know that only 600 of them have logged in during the last 2 weeks, your server can run like it only has 600 users.
It is true that Zulip writes a tiny UserMessage table row with (user_id, message_id, flags) for every active recipient of a message, we need to do so in order to track the unread state for all of those recipients (as well as related details, like mobile push notifications state). We need to write to that row a second time when the user reads the message.
With modern postgres and SSDs, writing 1000 rows is really cheap, and so part this is extremely fast when sending messages with 1000 online recipients, which isn't a thing real users do constantly anyway (since that's effectively an announcement, not a chat message).
Folks who are curious can read https://chat.zulip.org/#narrow/stream/3-backend/topic/send_m..., which is related optimization work we did this week that made it into this release.
(You could have a bad experience if you use remote storage that rate-limits "IOPS", though, because AWS at least used to count each row as an IOP and would use your full quota for 20s if you marked 20K messages as read with a 1000 UOP/s plan).
> It is true that Zulip writes a tiny UserMessage table row with (user_id, message_id, flags) for every active recipient of a message, we need to do so in order to track the unread state for all of those recipients (as well as related details, like mobile push notifications state). We need to write to that row a second time when the user reads the message.
No software architect here so I might be completely off the target but, is not read/unread count something that squares perfectly with the "eventually consistent" model? You don't need to write it down to the persistent storage right now as long as the client UI has it, then some kind of cache has it (so mobile can be in sync when refreshed) and then you persist it to the DB.
No software architect here so I might be completely off the target but, is not read/unread count something that squares perfectly with the "eventually consistent" model? You don't need to write it down to the persistent storage right now as long as the client UI has it, then some kind of cache has it (so mobile can be in sync when refreshed) and then you persist it to the DB.
We could certainly do something in that direction, but it'd be a lot of complexity (and risk of synchronization bugs) to avoid a few ~10ms of latency when sending messages to very large audiences.
Especially since that latency is mostly invisible, thanks to local echo: https://zulip.readthedocs.io/en/latest/subsystems/sending-me...
It's also not very high-value to optimize; that database write is 10-20% of the total time to process sending a message to everyone in a large open community like chat.zulip.org (with 18K total users).
Especially since that latency is mostly invisible, thanks to local echo: https://zulip.readthedocs.io/en/latest/subsystems/sending-me...
It's also not very high-value to optimize; that database write is 10-20% of the total time to process sending a message to everyone in a large open community like chat.zulip.org (with 18K total users).
Zulip is my favorite modern chat program because it's actually 100% FOSS, unlike Mattermost and RocketChat, which are only "open core" because they put a bunch of important features in closed-source enterprise modules.
Recently there was a an article about how everyone should just use e-mail. People would talk about slack/discord &ct. I find all of those to be strictly worse than e-mail for me.
Zulip is the only chat I've used that is better than e-mail for some purposes. It's got great export functionality and it's the only tool I've used that has better threading than e-mail. Every message has a thread, and therefore a subject, and you can dynamically re-thread sub-conversations.
Zulip is the only chat I've used that is better than e-mail for some purposes. It's got great export functionality and it's the only tool I've used that has better threading than e-mail. Every message has a thread, and therefore a subject, and you can dynamically re-thread sub-conversations.
We recently switched to it for work. The electron app is okay - but a real mac app would be nice..
Is there a chat app that is native anymore? I know Hipchat was back in the day, but the 2 I've used in recent years (Slack and Cliq) are both Electron as well. (As is Mattermost, but I haven't used it)
As someone who always has a terminal open, I consider Zulip Terminal[1] a native app.
1: https://github.com/zulip/zulip-terminal
1: https://github.com/zulip/zulip-terminal
Why would you need an app on the desktop? Honest question. I have used zulip in the browser for 3 years and I don't know what I would be missing.
Good question indeed, I'd say it comes down to:
- apps fit my workflow better - even if its just a different icon in the dock.
- having an actual non web tech based app would be great because web apps always behave slightly different than real native apps..
(It's really hundreds of small things that are just weird - always feels like you use a app in a portal..)
- having an actual non web tech based app would be great because web apps always behave slightly different than real native apps..
(It's really hundreds of small things that are just weird - always feels like you use a app in a portal..)
I really love Discord light theme
https://miro.medium.com/max/7168/1*iwfLW4rnn6U-mlUQpmBAfg.pn...
If Zulip had a similar theme, I really believe they’d covert way more non-tech individuals.
Longer post on discord light theme https://blog.discord.com/light-theme-redeemed-c541b7ab13e9
https://miro.medium.com/max/7168/1*iwfLW4rnn6U-mlUQpmBAfg.pn...
If Zulip had a similar theme, I really believe they’d covert way more non-tech individuals.
Longer post on discord light theme https://blog.discord.com/light-theme-redeemed-c541b7ab13e9
How many users can you handle on a server and how does it scale horizontally in terms of connections?
I love Zulip.
I've been self-hosting since the 3.1 or 3.2 release for a group of friends and the threading model works great, especially when you log in after a break (whether that's 8 hours to go to sleep or 2 weeks after a vacation).
When I was looking at setting up a chat server for me and my non-technical/mixed group of friends (so they couldn't use IRC and set up bouncers), I considered matrix, zulip, rocketchat, IRC, mattermost, and slack.
When I had issues (I use the docker install), the team was very responsive on their zulip server (chat.zulip.org).
For those of you already using Zulip, I prefer this dark theme over the standard (bright) blue one: https://github.com/zulip/zulip/issues/11845#issuecomment-544...
Thank you Tim and the Zulip team for the great software.
I've been self-hosting since the 3.1 or 3.2 release for a group of friends and the threading model works great, especially when you log in after a break (whether that's 8 hours to go to sleep or 2 weeks after a vacation).
When I was looking at setting up a chat server for me and my non-technical/mixed group of friends (so they couldn't use IRC and set up bouncers), I considered matrix, zulip, rocketchat, IRC, mattermost, and slack.
When I had issues (I use the docker install), the team was very responsive on their zulip server (chat.zulip.org).
For those of you already using Zulip, I prefer this dark theme over the standard (bright) blue one: https://github.com/zulip/zulip/issues/11845#issuecomment-544...
Thank you Tim and the Zulip team for the great software.
I am not familiar with the github sponsors, patreon and all ... I would like to sponsor them in the name of a company I run, do any of those options give me an actual invoice ?
Zulip is such a joy to use after other solutions. Threads are something that's hard to bend your team around at first (mainly non tech users), but they seem so obivous afterwards and it's hard to use another team chat without them.
One of the few things I wish it had was better admin and audit tools, because in my industry that is mandatory and while you can do it by poking the database yourself a reliable, featured tool would be great. As-is I use Zulip for internal chat and another solution for external (with customers).
In general, in its control panels and settings and options Zulip maybe feels a bit too "power user, then we restrict" than the other way around, eg when having an external user on my network it's a bit overwelming that their settings screen includes the entire org settings (but they can't change them). Pushing to your team is one thing, but when pushing something to customers or 3rd party any unwanted complexity is a major pain point.
Frankly in general Zulip doesn't LOOK like something you want to show to the people you ask money from (your customers), just like your car dealer doesn't want you looking at the inside of the car's engine. I know it's a difficult complaint to tackle because it's not about functionnality but purely perception.
Hope the team does well and looking forward to the future
Zulip is such a joy to use after other solutions. Threads are something that's hard to bend your team around at first (mainly non tech users), but they seem so obivous afterwards and it's hard to use another team chat without them.
One of the few things I wish it had was better admin and audit tools, because in my industry that is mandatory and while you can do it by poking the database yourself a reliable, featured tool would be great. As-is I use Zulip for internal chat and another solution for external (with customers).
In general, in its control panels and settings and options Zulip maybe feels a bit too "power user, then we restrict" than the other way around, eg when having an external user on my network it's a bit overwelming that their settings screen includes the entire org settings (but they can't change them). Pushing to your team is one thing, but when pushing something to customers or 3rd party any unwanted complexity is a major pain point.
Frankly in general Zulip doesn't LOOK like something you want to show to the people you ask money from (your customers), just like your car dealer doesn't want you looking at the inside of the car's engine. I know it's a difficult complaint to tackle because it's not about functionnality but purely perception.
Hope the team does well and looking forward to the future
Thanks for being interested in sponsoring us! Contact us (https://zulip.com/help/contact-support); there's a few options for how we might get you an invoice.
The product feedback on external guests is very helpful! You're encouraged to stop by chat.zulip.org and start threads in #feedback about each item if you'd like to help design how we address it, but in any case I'll discuss them with the community.
(For readers missing context, Zulip provides read-only access to many organization-level settings to normal users as a form of documentation on the organization's policies and what options exist that one might ask an administrators to adjust).
The product feedback on external guests is very helpful! You're encouraged to stop by chat.zulip.org and start threads in #feedback about each item if you'd like to help design how we address it, but in any case I'll discuss them with the community.
(For readers missing context, Zulip provides read-only access to many organization-level settings to normal users as a form of documentation on the organization's policies and what options exist that one might ask an administrators to adjust).
I use Zulip all the time at work.
It is ugly, sometimes will post to a different thread than you expect (not incorrectly, just the UI is very unclear where you are posting to), and has an infuriating tick that if you click off the the input box, it deletes everything you typed.
Otherwise, it gets the job done with minimum fuss.
It is ugly, sometimes will post to a different thread than you expect (not incorrectly, just the UI is very unclear where you are posting to), and has an infuriating tick that if you click off the the input box, it deletes everything you typed.
Otherwise, it gets the job done with minimum fuss.
Hmm, does it delete? I think it ends up in 'drafts'?
I have just registered to write the same thing :)
I think that must be the problem. It's not a very easy to discover feature and I was also pretty pissed about losing my messages — until I discovered the drafts.
I guess the idea was that once you exit the input box Zulip doesn't know which thread you are going to reply to — and in order to avoid sending messages to wrong threads it just clears the box (yet keeps your text). Makes sense in the threaded model, but could be highlighted a bit more.
We have tried using Zulip at my company and the main complaint has been UX.
Thanks for the feedback!
We know this is a real UX problem, and we're working on it.
Before Zulip 4.0, there was a "Saved as draft" notice that appeared on closing the compose box, but empirically, that was invisible to some users, who had the terrible experience of fearing their message was lost.
The 4.0 release replaces the notification with a darker and better located notification, which will likely help some users. But we'll only know for sure whether it's still invisible to some users with time.
In any case, we're planning several more changes to improve the drafts user experience that didn't make it into this release.
https://github.com/zulip/zulip/issues/17396 is one current issue on the topic.
We know this is a real UX problem, and we're working on it.
Before Zulip 4.0, there was a "Saved as draft" notice that appeared on closing the compose box, but empirically, that was invisible to some users, who had the terrible experience of fearing their message was lost.
The 4.0 release replaces the notification with a darker and better located notification, which will likely help some users. But we'll only know for sure whether it's still invisible to some users with time.
In any case, we're planning several more changes to improve the drafts user experience that didn't make it into this release.
https://github.com/zulip/zulip/issues/17396 is one current issue on the topic.
Well, lookit that. There is this drafts button, and I had not even realized it.
Thanks, you just made my day!
Thanks, you just made my day!
> it deletes everything you typed
It saves the message into your drafts
It saves the message into your drafts
Does anyone have any experience with both Zulip and Mattermost? Currently on Mattermost and wondering if it would be worth the hassle to switch. The threading does seem nice...
Mattermost isn't bad but not good either. I'd switch to anything else if it provides user friendlier interface but currently all the other open source alternatives provide even worse interface.
Mattermost CEO here, thanks for being a user!
We'd love to improve, are there one or two things top of mind for us to change?
We'd love to improve, are there one or two things top of mind for us to change?
Hi.
Here are my gripes. Minor but surely adds up when used everyday.
1. The reply button is too far away and small. It probably doesn't hurt to add text next to the icons like shown in the video in 4 to increase the click area.
https://i.imgur.com/DozvaBu.png
2. The replying message doesn't look intuitive, as, a bar to the left of a message looks like a quote instead of a live message I just typed.
https://i.imgur.com/lqefGBs.png
3. The quoted reply message's layout doesn't look right.
I really want a bit more roomy implementation than put everything condensed in 1 line. You can see a roomy implementation in 4's video.
https://i.imgur.com/voCziha.png
4. Quoting of messages
In another chat app (Chatwork), I can quote a message explicitly and I can also select a part of another message to quote only that, which is very useful when just responding to a part of another message especially when that message was long.
https://i.imgur.com/8dnqMZE.mp4
5. Not seen in the above video but if someone else quotes me, the whole message's background gets highlighted, so I can easily notice.
6. Mobile app needs to be able to access multiple servers but I'm sure you already have this request from many.
7. You said in another post that people get logged out automatically for security reasons but I think that puts a lot of inconvenience as I can only explain to those infrequent users it's some kind of bug because they wouldn't agree it's a "feature" when they lose further push notifications by not doing anything wrong themselves. This is the biggest reason I cannot recommend Mattermost when it can be seen as unreliable.
8. This is probably never going to be changed but I don't like that everyone has to join a global room when they join a team. I'd rather want people to only join specific channels. Kind of puts a wrong pressure to have everyone who don't even talk to usually in a same room and a possibility to type something wrong to everyone isn't a plus either. I can make many teams but that loses visibility to all the channels I belong to in a single view.
9. Ability to disable automatic formatting globally. It's always annoying when people just type symbols only to end up the message looking funny and I want to disable automatic formatting. In fact, I don't remember when I ever needed to format my message in a chat when I'm not composing a wiki page.
Simply typing "text[new line]---[new line]text" would yield this.
https://i.imgur.com/wcv8s7J.png
I still think it's the best self hosted chat solution but lack of much visible improvements for years (I know you're keep making constant updates on the server component) is making me lose much faith on where it's going.
1. The reply button is too far away and small. It probably doesn't hurt to add text next to the icons like shown in the video in 4 to increase the click area.
https://i.imgur.com/DozvaBu.png
2. The replying message doesn't look intuitive, as, a bar to the left of a message looks like a quote instead of a live message I just typed.
https://i.imgur.com/lqefGBs.png
3. The quoted reply message's layout doesn't look right.
I really want a bit more roomy implementation than put everything condensed in 1 line. You can see a roomy implementation in 4's video.
https://i.imgur.com/voCziha.png
4. Quoting of messages
In another chat app (Chatwork), I can quote a message explicitly and I can also select a part of another message to quote only that, which is very useful when just responding to a part of another message especially when that message was long.
https://i.imgur.com/8dnqMZE.mp4
5. Not seen in the above video but if someone else quotes me, the whole message's background gets highlighted, so I can easily notice.
6. Mobile app needs to be able to access multiple servers but I'm sure you already have this request from many.
7. You said in another post that people get logged out automatically for security reasons but I think that puts a lot of inconvenience as I can only explain to those infrequent users it's some kind of bug because they wouldn't agree it's a "feature" when they lose further push notifications by not doing anything wrong themselves. This is the biggest reason I cannot recommend Mattermost when it can be seen as unreliable.
8. This is probably never going to be changed but I don't like that everyone has to join a global room when they join a team. I'd rather want people to only join specific channels. Kind of puts a wrong pressure to have everyone who don't even talk to usually in a same room and a possibility to type something wrong to everyone isn't a plus either. I can make many teams but that loses visibility to all the channels I belong to in a single view.
9. Ability to disable automatic formatting globally. It's always annoying when people just type symbols only to end up the message looking funny and I want to disable automatic formatting. In fact, I don't remember when I ever needed to format my message in a chat when I'm not composing a wiki page.
Simply typing "text[new line]---[new line]text" would yield this.
https://i.imgur.com/wcv8s7J.png
I still think it's the best self hosted chat solution but lack of much visible improvements for years (I know you're keep making constant updates on the server component) is making me lose much faith on where it's going.
Appreciate the thorough feedback @mekster, this is super helpful,
Let me share a few resources that may help here:
- We're working toward delivering [collapsed reply threads](https://mattermost.com/blog/dev-sneak-peek-collapsed-reply-t...) in beta in the coming months. This feature offers improved visibility for reply messages and better UX for threading. Feel free to dive into the design files (https://www.figma.com/file/JmNM3WmTKHTKU5Cf7uNwOj/MM-18107-T...) to explore more, or come test out the work-in-progress on our community-daily build environment https://community-daily.mattermost.com/core/channels/folded-...) to share feedback about the progress.
- You've shared some really interesting ideas around quoting parts of messages. While it's possible to use the markdown `>` character to insert a quote, I think we can certainly improve here to make quoting more easily accessible. Would you be open to share your ideas on the feature idea forum: https://mattermost.uservoice.com/forums/306457-general
- We are working toward a v2 of our mobile app that will support connecting to multiple Mattermost servers and have improved team and channel navigation. We expect to open it up for beta testers later this year. You can check out the designs here https://www.figma.com/file/a9w2q3JnVvBwo2IScP8j3K/Phase-1-De.... Let me know if you have any feedback or thoughts!
- We allow System Administrators to customize session lengths to keep users logged in for longer if desired. We also offer an option for Administrators to enable automatically extending sessions with activity so users will stay logged in indefinitely as long as they have activity in Mattermost at any time within the specified session duration. You can learn more at: https://mattermost.com/blog/session-expiry-experience/
- We have some improvements for text formatting planned this year to make markdown formatting more user friendly. You can check out the designs here: https://www.figma.com/file/4fiyoFl9xZSeGXHZFqf5dw/MM-21168-A....
Again, hugely appreciate your thoughtful and detailed feedback as we iterate and improve.
I'd welcome you to join our contributor's workspace to continue the conversation there with our developers and product team via https://community.mattermost.com/core/channels/tickets
Let me share a few resources that may help here:
- We're working toward delivering [collapsed reply threads](https://mattermost.com/blog/dev-sneak-peek-collapsed-reply-t...) in beta in the coming months. This feature offers improved visibility for reply messages and better UX for threading. Feel free to dive into the design files (https://www.figma.com/file/JmNM3WmTKHTKU5Cf7uNwOj/MM-18107-T...) to explore more, or come test out the work-in-progress on our community-daily build environment https://community-daily.mattermost.com/core/channels/folded-...) to share feedback about the progress.
- You've shared some really interesting ideas around quoting parts of messages. While it's possible to use the markdown `>` character to insert a quote, I think we can certainly improve here to make quoting more easily accessible. Would you be open to share your ideas on the feature idea forum: https://mattermost.uservoice.com/forums/306457-general
- We are working toward a v2 of our mobile app that will support connecting to multiple Mattermost servers and have improved team and channel navigation. We expect to open it up for beta testers later this year. You can check out the designs here https://www.figma.com/file/a9w2q3JnVvBwo2IScP8j3K/Phase-1-De.... Let me know if you have any feedback or thoughts!
- We allow System Administrators to customize session lengths to keep users logged in for longer if desired. We also offer an option for Administrators to enable automatically extending sessions with activity so users will stay logged in indefinitely as long as they have activity in Mattermost at any time within the specified session duration. You can learn more at: https://mattermost.com/blog/session-expiry-experience/
- We have some improvements for text formatting planned this year to make markdown formatting more user friendly. You can check out the designs here: https://www.figma.com/file/4fiyoFl9xZSeGXHZFqf5dw/MM-21168-A....
Again, hugely appreciate your thoughtful and detailed feedback as we iterate and improve.
I'd welcome you to join our contributor's workspace to continue the conversation there with our developers and product team via https://community.mattermost.com/core/channels/tickets
It's nice to see a quick description of what the project is in the title
There's too many projects (even on the front page right now "Scala 3.0.0") for which I have no idea what they are, and I completely skim over.
There's too many projects (even on the front page right now "Scala 3.0.0") for which I have no idea what they are, and I completely skim over.
The Zulip Django source code (the "zerver" subdirectory) is a great read too. It's Python 3 with a lot of typing hinting (has no mypy errors).
Unlike a lot of Django code bases it heavily uses function-based views. It also uses relatively few third-party django apps.
Unlike a lot of Django code bases it heavily uses function-based views. It also uses relatively few third-party django apps.
We gave Zulip (and Mattermost, Element/Matrix, Rocket Chat etc) a try when our company was looking for self hosted alternatives to Slack. Zulip seemed like technically the most polished product. Smooth and easy get-running experience (Element was the polar opposite). Lightweight UI that doesn't feel buggy. I'd have liked to see a bit bigger font but what ended up being the showstopper was that new users were very confused about how to write in a channel (or stream how they call it). Everything needs to be in a second level "topic". In pretty much every other chat app one can just select a channel on the left and get a text input field where you can write your message. In Zulip though you don't get the text input. You have to either create a completely new topic which new users really don't understand or click on any of the past messages in the stream to create a reply to that topic (but not that specific message). I suppose it works well after you understand the messaging model but it represents such a high initial point of friction that we had to give up on it. Non-technical users had a really hard time and the switch from Slack was not high enough on the priority list to push through with it.
tabbot: if you happen to see this, please please consider some kind of easy-mode which:
tabbot: if you happen to see this, please please consider some kind of easy-mode which:
- by default always shows the text input no matter if you clicked on a stream or topic
- doesn't put the cursor in the "topic" input but the actual message input
- allows sending a message by pressing enter
- scrolls the window down when sending a message
- scrolls the window all the way down when clicking on a stream
- has a slightly bigger font size
- maybe also some simplification of the UI. You don't need the name of the stream above every message (see https://i.imgur.com/oeBY5yk.png )
I don't think the paradigm needs to change, I think the UI does (although I'm admittedly not clear what should be different).
To me the proof that the paradigm is good and it's a 'just' a UI problem is MS Teams. Teams has basically the same thread system - every message in a Teams channel is in a 'conversation'. When a whole org adopts Teams sometimes it takes some people a little time to learn not to create a conversation for every reply (my partner's company is non-technical and had this for a couple of people) but once you're going the system is clear to a new joiner. At my company (an engineering org) the thread system is universally used, works extremely well, and I've never encountered anyone who wasn't clear how it worked.
The big difference is that in Teams you don't have to name your 'conversation'. You can optionally give it a title if you want, but it's not necessary and that "what do I call it" step was always a bit of a mental speedbump in Zulip for my team.
To me the proof that the paradigm is good and it's a 'just' a UI problem is MS Teams. Teams has basically the same thread system - every message in a Teams channel is in a 'conversation'. When a whole org adopts Teams sometimes it takes some people a little time to learn not to create a conversation for every reply (my partner's company is non-technical and had this for a couple of people) but once you're going the system is clear to a new joiner. At my company (an engineering org) the thread system is universally used, works extremely well, and I've never encountered anyone who wasn't clear how it worked.
The big difference is that in Teams you don't have to name your 'conversation'. You can optionally give it a title if you want, but it's not necessary and that "what do I call it" step was always a bit of a mental speedbump in Zulip for my team.
Yes I agree that is pretty much purely UI issues. I don't want the paradigm to change. I guess I could have made that a bit more clear in my initial post.
Thanks for the feedback! It's much appreciated.
We are actively working on several ideas in this space. (One of the most important that was released in 4.0 is the redesign of the Reply button to make starting a reply feel like it does in other chat tools).
I expect we'll be able to get into a really nice place with a combination of new settings with some mixture of "Easy mode" defaults, design changes, and onboarding adjustments. (We will do this while carefully preserving model/paradigm, in case anyone's worried). Feel free to stop by chat.zulip.org if you want to discuss specifics.
FWIW, we regularly hear from large organizations, including some with thousands of nontechnical users, about their having great luck migrating to Zulip. Usually they tell us they did a 30-minute training and then things went smoothly from there, or they didn't and it took a couple weeks for some users to get the hang of it.
In the scheme of things, doing a training is a pretty minimal investment to be able to use a better product for hundreds of hours a year. But of course Zulip would grow a lot faster if nobody worried whether their nontechnical users will thrive on it, so this area is a priority for us.
We are actively working on several ideas in this space. (One of the most important that was released in 4.0 is the redesign of the Reply button to make starting a reply feel like it does in other chat tools).
I expect we'll be able to get into a really nice place with a combination of new settings with some mixture of "Easy mode" defaults, design changes, and onboarding adjustments. (We will do this while carefully preserving model/paradigm, in case anyone's worried). Feel free to stop by chat.zulip.org if you want to discuss specifics.
FWIW, we regularly hear from large organizations, including some with thousands of nontechnical users, about their having great luck migrating to Zulip. Usually they tell us they did a 30-minute training and then things went smoothly from there, or they didn't and it took a couple weeks for some users to get the hang of it.
In the scheme of things, doing a training is a pretty minimal investment to be able to use a better product for hundreds of hours a year. But of course Zulip would grow a lot faster if nobody worried whether their nontechnical users will thrive on it, so this area is a priority for us.
On a similar note, my company switched to Google Chat which has threaded rooms (not commenting on the implementation here). A lot of new users, probably a majority even, always post messages in the latest thread, instead of creating a new one. They just find the only text field there is and type there.
The fact that Zulip is threaded (and this threading is enforced) is what makes it so valuable, at least to me.
Your proposals would get rid of its main feature and go completely against one of its core ideas.
Your proposals would get rid of its main feature and go completely against one of its core ideas.
I kinda agree. Actually what I wanted to say is I see where you are coming from but I disagree that my proposal would get rid of its main feature. I just want some way to have easy defaults for new users. I wouldn't propose to remove any features. You should still be able to do whatever is possible right now and for the advanced users nothing would change. I suggested an additional easy mode to help new users. This could be set as default by the organization admin or just make it opt-in. Nobody should be forced of course. I am confident that it would be still possible to push users into using threads/topics but without the considerable friction that currently exists. The fact that Zulip has to include these little tutorial bubbles for new users to show them how to write a message and other chat apps don't need it shows that Zulip is more complicated to understand and use as a newbie.
Right, I can see that, thanks for clarifying.
I had a similar experience with Zulip when I tried to set up a chat tool for our research group. I liked the ideas of topics and such, but other people weren't so enthusiastic to learn about a whole new chat paradigm. In the end we switched to Mattermost and we are quite happy with it.
Mattermost doesn't seem to be improving at all for years.
I just don't get how it's difficult to reply or quote someone's message when it's such a basic chat feature.
Instead they invent weird code like "shrug" thinking it's funny during business chat.
Also I often get logged out of mobile app and notifications stop reaching which makes it very unreliable as a business tool.
They need to fix where it matters.
I just don't get how it's difficult to reply or quote someone's message when it's such a basic chat feature.
Instead they invent weird code like "shrug" thinking it's funny during business chat.
Also I often get logged out of mobile app and notifications stop reaching which makes it very unreliable as a business tool.
They need to fix where it matters.
Mattermost CEO here, highly appreciate the feedback,
On logging out of mobile apps, often that's from an IT security policy to have sessions last only a fixed number of days from the last login.
We added a feature to automatically extend the session length based on the last login of a user--so inactive users get their sessions expired for security, and active users don't.
If you're a long time user of Mattermost you might need your IT admin to switch on the setting: https://mattermost.com/blog/session-expiry-experience/
It was set to be on by default in Mattermost v5.24.
Regarding replying, we've been working with our community on adding different options for threading: https://mattermost.com/blog/dev-sneak-peek-collapsed-reply-t...
From the blog post you can join the discussion on the topic if you like as well. We're very open to your feedback,
On logging out of mobile apps, often that's from an IT security policy to have sessions last only a fixed number of days from the last login.
We added a feature to automatically extend the session length based on the last login of a user--so inactive users get their sessions expired for security, and active users don't.
If you're a long time user of Mattermost you might need your IT admin to switch on the setting: https://mattermost.com/blog/session-expiry-experience/
It was set to be on by default in Mattermost v5.24.
Regarding replying, we've been working with our community on adding different options for threading: https://mattermost.com/blog/dev-sneak-peek-collapsed-reply-t...
From the blog post you can join the discussion on the topic if you like as well. We're very open to your feedback,
That is also the impression we got when we tried Mattermost. It came as a big surprise because we are using a selfhosted Gitlab instance and Mattermost is supposed to have great integration with Gitlab but it really didn't work well. Maybe it is due to us having set up Gitlab within Docker, I don't know. In the end we got it working but it still didn't recognize a user from Gitlab. It really felt like they had some good start and ideas but then something changed and came to a halt.
Mattermost CEO here, thanks for the mention and the feedback!
Just curious, have you enabled the GitLab-Mattermost plugin? https://github.com/mattermost/mattermost-plugin-gitlab#confi...
If it wasn't easy to find, that's on us, and we need to do a better job in making things more discoverable.
Just curious, have you enabled the GitLab-Mattermost plugin? https://github.com/mattermost/mattermost-plugin-gitlab#confi...
If it wasn't easy to find, that's on us, and we need to do a better job in making things more discoverable.
The bundled Mattermost was a bit flaky IIRC but with a separate instance (in Docker) using Gitlab SSO was no problem.
Using SSO for Sentry was a bit more problematic as it's an unofficial plugin but IIRC it was due to Gitlab not sending the correct scope.
Mattermost CEO here, thanks @jdiez17! Very glad to hear!
All it really needs is default topics for each stream when you click on the stream. Like Discord's #general
The Rust project uses Zulip and I love it.
The onboarding cost is real, it takes ~5 min for someone to learn the tool which is far above the expectations of most users that expect it to just be "a chat".
The onboarding cost is real, it takes ~5 min for someone to learn the tool which is far above the expectations of most users that expect it to just be "a chat".
not seeing any mention of encryption
Zulip uses standard HTTPS encryption for traffic and Argon2 for passwords. See https://zulip.readthedocs.io/en/latest/production/security-m....
With Zulip, why do you need two namespaces for every chat content? I find it hard to understand it, and thus it hasn't clicked with me yet.
One namespace (Stream) is a long-lived, durable category. The second namespace (Topic) is the specific conversation you're in and is more like an email subject line.
Topics are lightweight and can be split, merged and moved around as needed.
Topics are lightweight and can be split, merged and moved around as needed.
I have some experience with Zulip through the rust zulip server and I have to say as far as I can tell Zulip is the best choice for this kind of communities.
The threading model might not be the best choice for all use-cases, but for a open-source project related community its superb (IMHO).
The threading model might not be the best choice for all use-cases, but for a open-source project related community its superb (IMHO).
Many thanks to the Zulip team and all who have contributed to this amazing project. We went live on 4.1 and appreciate the bug free installation and there being no ‘Enterprise Only’ features. Inclusion of Active Directory integration was a key must have feature for us. We use Zulip to communicate between 9 separate organizations that happen to share a common app that uses AD for authentication so having to not have an additional password was awesome. We have been anxiously waiting for some features in this update and will be installing it in a couple of weeks. This project imho is exactly what open source should be. Kudos!!!
I took a quick look at the website, but couldn't answer my question quickly. Is Zulip suitable for integrating into an existing application where everything happens within the app?
I am working on an application that needs chat and user-to-user messaging and it needs to happen in the app. Options like Slack, Discord, Mattermost aren't suitable.
This really isn't something I want to write from scratch. .NET Core based App FWIW.
I am working on an application that needs chat and user-to-user messaging and it needs to happen in the app. Options like Slack, Discord, Mattermost aren't suitable.
This really isn't something I want to write from scratch. .NET Core based App FWIW.
Mattermost PM here, thanks for the mention and the feedback!
We have seen some users integrate Mattermost into an existing application. I'm not sure if these resources may be helpful? - docs.mattermost.com/integrations/embedding.html - https://forum.mattermost.org/t/recipe-embedding-mattermost-i...
If you have any questions or feedback, would love to hear as well.
We have seen some users integrate Mattermost into an existing application. I'm not sure if these resources may be helpful? - docs.mattermost.com/integrations/embedding.html - https://forum.mattermost.org/t/recipe-embedding-mattermost-i...
If you have any questions or feedback, would love to hear as well.
is there anyone here old enough to remember Lotus Notes from the 90s? what does Zulip offer that I couldn't do then? (plus being able to then develop custome views, forms, etc)?
Would love to use Zulip for work but right but forwarded emails end up being empty and our current office is still currently email-centric. Teammates and management won't use if it they can't interact with it via email.