Zulip Server 1.9: HipChat import and much more
blog.zulip.org
blog.zulip.org
It's definitely possible to run a Zulip server with essentially no downtime. E.g. the main zulipchat.com service has had approximately 10 user-facing outages with a median duration of 5-10 minutes over the last 5 years (there was one while we still only had a few hundred users that lasted overnight), most of them in the middle of the night. Happy to talk more about this for anyone curious; there are some fun stories (like migrating from MySQL to Postgres as our primary database technology with <30 minutes of downtime early in its development).
We don't have a public uptime SLA for zulipchat.com uptime yet, but we're happy to make them for individual customers (and I suppose we should add one).
If you're self-hosting, our commercial support offerings will help you setup your servers in a way that achieves your uptime goals; because Zulip is so stable, usually folks just go with a hot spare (our enterprise customers generally only report downtime related to server upgrades, which is usually avoidable).
But this comment on the zuplipchat web site https://zulipchat.com/security/ feels like a pretty gross generalisation and detracts from Zulip's vibe IMO:
> With many SaaS providers, essentially all engineers have direct shell access to production servers storing user data. Zulip Cloud is different: only a small handful of security-trained engineers have access to production servers or to sensitive customer data.
I really appreciate the feedback!
A bunch of other cool open source projects use it, including Python Core, parts of the Rust community, MariaDB, Coala, the Lean Theorem Prover, the HL7 standard, and many more.
That's what I did. Thanks again to them, I really appreciate it.
Reddit was OK for awhile... I dislike the redesign because there are bugs with code formatting, and because the latency is worse. And it seems like they couldn't really make up their mind visually.
Actually Zulip is one of the lowest latency web apps I've used in recent memory!
I also have problems following IRC because of the lack of threading.
Am I reading the docs correctly in that email is absolutely required? I haven't checked thoroughly for this new release, but previously it was for missed message notification as well as account creation, if I'm remembering right.
It's not a for profit place, so I'm simply looking to self host, sans email, to make communication easier across the teams. Current solution is definitely inferior to Zulip!
Send a message in "#production help" in chat.zulip.org if you have trouble figuring it out, and I'll extend the docs until you can get it working.
I don't think I would have located this option while filtering for "works without email, and I'm okay missing messages". If it was present a year ago I definitely didn't. Very glad it's a supported corner case!
The other really neat feature was having multiple "teams" on a single server.
edit: link updated to point to official documentation instead of github
From a quick glance, the differences I see are: * In mattermost, different "teams" (or "realms" or "namespaces", whatever) exist on the same server (same url), and a user account that logs in will only see the teams they are assigned to. A single user account can be assigned to multiple teams (they appear on the left, similar to how the slack desktop app shows multiple server connections).
* Zulip requires a different subdomain for each "realm", and it sounds like users have to log into each one separately. It is not clear if the same account is shared between organizations or a user must have separate accounts.
So it sounds like Zulip's approach is separate, isolated "organizations", like slack, just hosted on the same server. Where Mattermost's approach is more like having separate, but integrated teams/groups/namespaces that a single account can be part of.
Correct. But Zulip does allow to import settings, profile picture etc from an existing account during signup if the email remains the same.
git shortlog -ns
git shortlog -sn --no-mergesIn personal projects or those with fewer developers, I prefer rebase + FF merge for a clean history. I don't really feel the need to see the merge commit in the master branch history.
i think the core of it comes down to the UX for "git log", which attempts to display history linearly when in fact it absolutely is not. ask yourself: what is the _contents_ of a merge commit? if you know git well, you know that the merge commit contains everything from the feature branch... and that the feature commits you see when you run "git log" on master are actually not on master at all. so the rebase strategy makes master truly linear to match the tools and reduce cognitive load.
however, the rebase strategy does introduce new possibilities of tool-driven bugs and requires more rigor. this article has a good run-down of the risks:
https://medium.com/@fredrikmorken/why-you-should-stop-using-...
the classic example of a rebase pitfall is:
a) you branch from master,
b) on your feature branch, develop a feature utilizing dependency x,
c) meanwhile, on master, another developer removes dependency x,
d) you rebase back on top of master -- there are no conflicts, and things look good, but the build is completely broken.
It takes a little more work for each contributor but leaves history on master very clean.
For this reason, most major open source projects use that part of the workflow (asking their contributors to rebase their PRs on top of master and never use `git pull --merge`), even if they plan to merge the commits into master via a merge commit.
(The Git documentation is very aggressive in discouraging force-pushing of commits, but that advice is intended for a public repository, like the main zulip.git repository, that others might pull from. Obviously, we don't force-push to zulip.git, but if you're using Git right, you should be force-pushing to your fork when you fix a typo in one of your commits.)
For me it's Zulip Topics - they make it very easy to organize the communication. You have channels and they contain topics. This is one of the most useful features of Zulip.
Most features of all chat clients (riot, slack, mattermost, rocket.chat, zulip) are pretty similar.
Redis, Postgres, Rabbitmq and Memcached just to run a chat?
It is neither a tech demo nor a product, it is a mature open source project.
In fact, in my mind tech demos tend towards having fewer mature components.
> Redis, Postgres, Rabbitmq and Memcached just to run a chat
That set of dependencies seems quite normal to me for a mature project. Mastodon (the most popular open-source-twitterish-thing) has a similar set of dependencies, and is also effectively just chat as you say.
Discourse, a popular open source forum, is also basically just chat, and has a similar set of dependencies.
In the case of zulip, you can even use a hosted version and avoid running anything yourself.
I don't understand why its totally normal set of dependencies turns you off so harshly. I'll happily take a project using redis/postgresql/etc instead of trying to build its own versions of those baked into the binary because components like postgres/redis/etc have great documentation, tooling for metrics and monitoring, etc... If the project bakes its own stuff in itself to avoid taking on dependencies, I doubt it will either be as good or as easy to manage.
https://zulip.readthedocs.io/en/latest/production/install.ht...
> just to run a chat
Don't overlook the fact that this is a scalable and stable solution used by many companies with thousands of users for each instance. I would have my doubts about the project if it wouldn't use those components.
Has this been fixed/improved?
We're looking at paying for Slack and mattermost seems to offer most of what Slack does and is something that would be pretty easy to run. It's slick. Well documented and installs nicely in a container.
Has anyone here used Mattermost?
Both mattermost and zulip look well worth it for saving quite a bit of money over slack for a fair sized company though.
The responses from people here are really interesting.
We only have/had a short eval phase and our use case is a small raceengineering team with 40 people at the racetrack, independent of internet access. So a very particualar use case, and our needs might not cover you needs.
Zulip pro
* Threading model (can't value that high enough)
* All messages overview, no matter what stream they were written in
* Zulip community at chat.zulip.org with direct contact to the devs. Tim Abbott the lead dev helped me out in a issue with a user login (haven't used the Mattermost support so can't compare)
Zulip con
* Most ops work has to be done by a python script manage.py, API has room to improve
Mattermost pro
* API
* haven't measured but the UI felt smoother, faster
Mattermost con
* you have to pay for Enterprise features
Both have great docs and a docker deployment
Our use case is basic chat features with some integrations for a team of around 40.
We run it in a t2.small instance along with another tool. I only had to manually restart it once, which is fine by me.
A postgres backend and S3 storage is most welcome and makes it very simple to manage.
My only complaint would be that the config file is not included in the postgres database so you need a separate routine for its backup. (If anyone from Mattermost reads this, please just include it in the database)
It could also handle importing multiple emojis for us Hipchat castaways.
With the addition that Mattermost is open core, not fully open source.
More on their homepage - https://zulipchat.com/
The idea is you subscribe to a channel, but then any post to the channel needs to also have some sort of logical subject.
Zulip, used well, ensures that the messages are partitioned into different conversations, so you can easily do things like skip to the bottom of a long thread to see if it ends in a satisfactory resolution, without missing the unrelated question that you need to answer.
Here's our thinking. Topics within a stream are ordered by the time of the most recent message. We keep the complete history, both of messages and topics, because it's useful for search and following up on things. Personally, I regularly reply to a conversation whose last message was a month or more ago to follow up with new information (often after getting there from one of the permanent links in our issue tracker). Because the context is all there and available with just a single click on the topic, I find it to be a really nice workflow.
We actually just had a discussion of it last week; the issue created from that is here: https://github.com/zulip/zulip/issues/10786
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.
In any case,
* You can enable "Enter to send": https://zulipchat.com/help/enable-enter-to-send
* Private Messages (called DMs in Slack) in Zulip work the same way they do in Slack, with an open-by-default compose box.
If this is the intention, then I'm baffled at how you intend your product to be used. Your advertisement of Zulip is completely at odds with... its fundamental principle? What I mean is, your website says "Zulip combines the immediacy of real-time chat with an email threading model", but it seems you're explicitly designing away the immediacy and requiring people to spend significant time thinking about what to type and clicking around to find the appropriate thread to reply to, just like with email. It can't function as a team chat system if it doesn't facilitate instant messaging -- "chat" systems are designed pretty much by definition to allow instant communication. (Like what "chatting" meant, before computers were around.)
What you really seem to have is a shared-inbox email service -- kind of like a mailing list, but in a shared workspace, which would produce something that's more close to the exact opposite of your description... something like: "Zulip combines the deferred/asynchronous model of email with the shared-inbox nature of a mailing list".
So here's my question: what do you expect teams to do when they actually need instant communication with the rest of the team? Do you expect them to have another (actual) chat system in parallel for that, or do you intend a model where you intentionally insert obstacles to make that viable somehow? I'm not talking about stuff you'd put in a email, so I'm not talking about something like "Let's discuss item 2 on the design doc. I think it would be better to approach the problem by doing X, then Y, then Z. This benefits us because Y helps us with Z and [blah blah]." I'm talking about stuff where there is something urgent going on and immediacy is the #1 priority, like "can s/b urgently cover me here I gotta run" or "what's up w/ the projector in C13?? I have a meeting" or "who's covering the slot rn? s/b's waiting" -- you know, the day-to-day stuff where the extra 10 seconds finding the right topic to reply to and the extra O(minutes) trying to articulate an eloquent email-like message for your team is going to tick everyone off (especially outside clients etc.) rather than please anyone. This kind of immediate communication is what teams need instant messaging systems like Slack for -- if your software is explicitly designed to discourage it, what do you imagine continuing to fulfill this need after teams switch to Zulip -- another parallel Slack?
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.
The thing I don't get here is you have two competing claims/goals, both of which I could buy in isolation and in fact agree are perfectly reasonable goals, but both of which actively contradict & fight against each other. On one hand you believe it'd take the same amount of time as before if people would only learn to use the system as designed (which I'll take at face value here), but on the other hand you say "the medium correspondingly encourages more multi-line, thoughtful posts". Writing more thoughtful messages and coming up with subject lines by definition requires more time... how can it not?
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.
> you say "the medium correspondingly encourages more multi-line, thoughtful posts". Writing more thoughtful messages and coming up with subject lines by definition requires more time... how can it not?
I think the key here is that you can write more multi-line, thoughtful posts, and they come through and sustain a real conversation much better than they do on Slack or IRC. But when that's not what's called for, you can also write super-quick short messages too.
For example, a few months ago the Zulip developers gathered in one place for a week to hack together. We had a stream (~channel) for the event, and one frequent topic in it was "schedule". A lot of the messages there were like "@all dinner's ready" -- dashed off on a phone, notifying everyone in the group, so a lot like sending to a WhatsApp group.
But other messages on the same topic were things like the next day's schedule or some detailed logistics, sent from a laptop with a real keyboard. It was helpful to have those details in the same thread as context above the quick right-now updates.
Other topics contained a variety of side discussions, some consisting of quick short messages ("found an X, who lost it?"), others detailed and thoughtful. A lot of those would have been lost in the noise in a Slack channel or a WhatsApp group, or would have added noise to make the other conversations hard to follow, or both.
And it was extremely helpful that all of the above was in the same system that we use all the time for in-depth technical discussion and other collaboration.
I really don’t understand it myself, since it looks more or less the same as other apps, but my instinctual reaction is still ‘yuck!’.
- The UI looks better the more streams you are subscribed to
- The UI just "works"
I'm still not sure if the UI works because it is not distracting me with good looks ;)
On the bottom of the page, it reads:
Tim Abbott is the lead developer of the Zulip open source
project. He previously was CTO of Ksplice and then Zulip
Inc. (before it was acquired by Dropbox).Here’s an Techcrunch article from Mar 17, 2014 [1].
[1] https://techcrunch.com/2014/03/17/dropbox-acquires-zulip-a-s...
It seems a bit like a slakey zulip to me, though I haven’t had opportunity to use it yet.
But of course that's not to say that there is anything wrong with the quality of the product being promoted here.
"Zulip now has an IRC bridge powered by matrix.org"
See: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
(not saying this is the case here, just that it shouldn't be a concern)
[1] https://zulip.readthedocs.io/en/latest/production/mobile-pus...
For what it's worth Zulip was at the top of our list when we evaluated hipchat replacements. Happy to look at it again if you ever will have direct notifications.
From what i remember - Rocketchat was based on meteor, which seemed dying at the time + it was computing hungry and clients were especially hungry. - Mattermost worked for a time but you were not able to get mobile notifications without paying for license (not sure about now). Sounds suprising but it was just problem. - Zullip too many dependencies and complicated install.
Matrix is more of a standard than anything. The first server implementation is called Matrix Synapse written in python twisted. I had it running without issues on 512mb vps for 30 people org with SQLITE. When you need bigger scale Matrix has some go and rust server implementations, you can also use postgres etc.
I guess you should start with what scale you need and what features you need and go from there.
It's basically hosted Slack-using-riotchat/matrix.
Very cheap too. Most of the other open source providers (incl Zulip and Mattermost) almost cost the same as slack.
Only Synapse is usable though. Dendrite (Go+Kafka) is getting there, but Ruma (Rust) seems to have been stalled waiting for the programming language to stabilize.
Sorry for incomplete info.
What are the steps involved? For us, it's "tap the phone icon in the top right".
So it's becoming clear that the only revenue model going forward is open core model.
I hang out on freenode every day. But I have higher expectations of chat in 2018 when it comes to what I would choose for an actual organization. So does everyone else.
IRC isn't blowing anyone's mind. Especially that first time they try to reply to someone but their message is never received because the other person closed their laptop.