My guess is most of the major chat players handle this pretty easily -- it's a non-starter for many potential users if you don't. Zulip stores all data indefinitely (including message edits, etc) in its default configuration.
In case anyone runs into this in the future, Zulip has a few features that could help:
* You can set a message retention policy that will delete each message after N days. (We're building the UI for it, but currently you can email [email protected] for help on turning it on.)
* On Zulip Cloud, you can set a message visibility limit that will save all your messages (e.g. for legal/compliance reasons), but only the last N messages will be visible to the team.
https://zulipchat.com/help/moderating-open-organizations has some of that info.
Zulip doesn't have IP-level banning or moderation tools (at least not at the organization admin level; maybe you could hack something together if you were self-hosting).
I agree that on the benchmark of time-to-send-a-message, Zulip is slightly slower than Slack, which is in turn slower than just putting the whole company in a WhatsApp group.
But the end goal is not sending messages, the end goal is getting the person who knows about the projector to see your message and respond, for you to see that response, etc.
In a moderately sized company, Slack is better than the WhatsApp solution, since you can direct the message at roughly the correct set of people, by spending the extra time to choose a channel. In turn, those people are more likely to get the message in time to act on it, because the message won't be buried under tons of messages meant for other people in the company.
Zulip takes that a step further, by adding subject lines to messages. The same tradeoff applies.
I think in the end the question really is how much more work it is to add the extra signal. The best case would be you could send messages like in WhatsApp (no subject line, and every message goes to the entire company), and read messages like in Zulip (subject lines, and with channels limiting audience). For both Zulip and Slack, the premise is that we can drive down the cost of adding the extra signal to low enough.
I think the short answer is that there is some learning curve to using Zulip, but once that's done, sending messages like that takes essentially the same amount of time it would in another product.
The actual extra actions are:
* up to one extra keystroke to open the compose box
* typing a subject line like "projector C13"
You wouldn't have to search for a topic to send a message like that; you would just start a new topic. And "what's up w/ the projector in C13?? I have a meeting" would still be a perfectly fine Zulip message.
And then on the receiving end, you actually save a bunch of time.
* There's a simple keyboard shortcut ('n') to see the message that just came in.
* The fact that there's a subject line means that everyone sees "projector C13" and decides if they're a person that can respond to that, even if they aren't caught up on the rest of the channel.
* If someone does respond, you can see that they responded to your message, and not to some other conversation that's going on in the channel. That makes it easier to keep an eye on the conversation while the rest of you is improvising a solution.
Slack and Zulip are implementing pretty different communication models.
In Slack, most messages are a single line, and are very real-time. E.g. if a channel is getting 100 messages a day, and a conversation starts in the morning, you're not going to try to engage with that conversation even that afternoon.
In Zulip, communication is asynchronous by default. This has a lot of secondary implications; e.g. it means that by default you can assume people will see your message, rather than just the people that check in the next few hours. This means you can have substantive discussions on the platform, and the medium correspondingly encourages more multi-line, thoughtful posts. So we've currently decided that having to type an extra letter to compose is worth the tradeoff.
As an example, not having compose open by default allows us to use single letter keyboard shortcuts for navigation.
Zulip supports itself by selling hosting (at zulipchat.com) and support contracts for on-prem installations. Everything is a part of the open source project; no proprietary add-ons.
I work on Zulip, so will only attempt an answer for that. Zulip is designed to scale team chat past when you're getting 1-200 messages a day.
With an IRC- or Slack-like communication model, waking up to 100+ new messages every morning is a big drain on time and energy. Also, once a channel starts getting 100+ messages a day, it stops being useful for real communication. If someone starts a conversation at 10am, and you come by after lunch, it's hard to respond in context.
You can see how Zulip solves this problem on the Zulip community server, https://chat.zulip.org (send test messages to "#test here", follow the code of conduct, etc., it's a live server). Feel free to PM me there if you set things up and have any questions/feedback.
To address a previous post: Zulip, Mattermost, and Rocket.chat all take about 5 minutes to install, so I wouldn't worry too much about that. Zulip and Rocket.chat also come with SaaS versions if you don't want to run your own infrastructure.
Zulip | Designer | San Francisco | ONSITE (preferred) + REMOTE | Full time or part time
Zulip is an open source team chat product, with dozens of weekly active contributors, and an experienced core leadership based in SF (https://zulipchat.com/team/). You can check out the product at the Zulip community server, https://chat.zulip.org.
We're looking for a strong UI/visual designer. The ideal candidate has strong CSS and visual design skills, and is comfortable doing the basics with javascript, html, and git. You would be Zulip's first full-time designer, responsible for moving the overall design of Zulip forward, including developing a style guide, implementing most of the design and CSS work for new features, and working closely with frontend and full-stack engineers.
Pay is competitive. One of the big perks of working for Zulip is that all of your work will be open sourced and available forever.
Email us at [email protected] with a resume/portfolio, and we'll take it from there. Women and minorities encouraged to apply.