
Zulip Server 1.9: HipChat import and much more - rishig
https://blog.zulip.org/2018/11/07/zulip-1-9-released/?n=1
======
nicholasjbs
We (the Recurse Center) have been using Zulip since early 2013, and it is the
core of our online community. Zulip is excellent both for small teams (we use
it for our team of 7) and big groups - we also run a realm with over 1,000
users posting 10s of thousands of messages monthly. I can't recommend it
highly enough.

~~~
erinnh
How do you handle high availability for Zulip? Last I looked that was a
problem for it.

~~~
tabbott
Zulip founder here.

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).

------
jsiepkes
I've said it before (so at the risk of annoying people ;-) I can highly
recommend Zulip. We briefly used Mattermost (couple of months) before
realising the Zulip threading model was a way better fit for us then what
Mattermost offered. It might feel a bit odd in the beginning but after you've
become accustomed with it you'll love it!

------
abraae
I love Zulip and wish it the best.

But this comment on the zuplipchat web site
[https://zulipchat.com/security/](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.

~~~
tabbott
Yikes, I'm not sure how "essentially all" ever got in there; it should have
been "the majority of". And even with that edit, our practice is, where
possible, to cite sources, and while there's a lot of anecdotal data on this
topic, there aren't great published sources for this topic. So whether or not
it's shockingly common for companies to have dozens or hundreds of people with
shell access to production, we've removed the commentary on what other
organizations do here, and just explain our practices.

I really appreciate the feedback!

------
raphlinus
We've been using Zulip for just over a week in xi-editor and related projects,
and I'm thrilled. Huge improvement over the pastiche of IRC and Reddit we were
using before.

~~~
tabbott
Zulip founder here; I should add that Zulip hosting is free for open source
projects: [https://zulipchat.com/for/open-
source/](https://zulipchat.com/for/open-source/).

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.

~~~
StavrosK
How do you get the standard plan for an open source project? I don't see
anything on that page or anywhere else, should we email the team for the bump?

~~~
raphlinus
"Just contact sales@zulipchat.com and we’d be happy to discuss your
situation!" ([https://zulipchat.com/plans/](https://zulipchat.com/plans/))

That's what I did. Thanks again to them, I really appreciate it.

------
zafiro17
I'd looked into Zulip a few months ago when it appeared on HN and it looks
great to me. But this announcement mentions a new beta terminal client! That
seals the deal for me! Love the idea of Zulip on a terminal: too good to be
true for my organization at least.

------
hiisukun
I'd love to set this up at my part time workplace, but it's a forensics shop
where the network is offline, and doesn't have email. Team is small (<20) so
manual accounts would be fine.

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!

~~~
tabbott
We support this, it's just enough of a corner case that it's not well
documented. If you don't care about missed-message emails, you can install the
Docker image (easiest to setup when offline), and then use
[https://zulip.readthedocs.io/en/latest/production/authentica...](https://zulip.readthedocs.io/en/latest/production/authentication-
methods.html#apache-based-sso-with-remote-user) with an Apache .htaccess file
as the thing that sets REMOTE_USER.

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.

~~~
hiisukun
Well, that's a great reply. Having read quickly through the docs, I think in
particular the "Life of an Apache-based SSO login attempt" had enough
information to clarify the process for me - until then I wasn't as sure.

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!

~~~
tabbott
Yeah, the front-page documentation focuses pretty heavily on "you should setup
email" because it helps folks in a normal environment successfully setup Zulip
quickly and reliably. I'm not sure whether this use case is common enough that
we should put it in the front-page docs, but possibly we should write
something that Google will find...

~~~
bj0
I looked at Zulip vs Mattermost several months ago and, if I recall correctly,
this was one of the primary reasons I went with Mattermost. I just wanted
something I could spin up in docker on a vps without having to setup anything
else (like an email server). Mattermost lets you generate "invite links" that
you can just paste in a chat or text message.

The other really neat feature was having multiple "teams" on a single server.

~~~
seedie
Hi, I don't know enough about Mattermost to be sure I understand you correctly
about 'multiple "teams" on a single server' but you can host multiple
organizations (realms in zulip-speak) on a single zulip server
[https://zulip.readthedocs.io/en/latest/production/multiple-o...](https://zulip.readthedocs.io/en/latest/production/multiple-
organizations.html)

edit: link updated to point to official documentation instead of github

~~~
bj0
That's neat, I may look at zulip again if I need to setup another server.

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.

~~~
vishnu_ks
> So it sounds like Zulip's approach is separate, isolated "organizations",
> like slack, just hosted on the same server.

Correct. But Zulip does allow to import settings, profile picture etc from an
existing account during signup if the email remains the same.

------
tedmiston
It's pretty cool that he included the output of

    
    
        git shortlog -ns 
    

in the release announcement.

~~~
amdelamar
I liked that too. But I prefer to hide merge commits using:

    
    
        git shortlog -sn --no-merges

~~~
tabbott
Zulip has a rebase-based development workflow and doesn't use merge commits
because in my experience, it produces a much more readable commit history
(which is really important for understanding historical changes). We've been
very happy with this approach. Some relevant reading on our version control
approach for those who might be interested: *
[https://zulip.readthedocs.io/en/latest/git/overview.html](https://zulip.readthedocs.io/en/latest/git/overview.html)
*
[https://zulip.readthedocs.io/en/latest/contributing/version-...](https://zulip.readthedocs.io/en/latest/contributing/version-
control.html)

~~~
jtchang
Doesn't using rebase generally mean you have to rebase on top of master and
thus with your local branch you may need to git push --force ?

~~~
rekwah
You rebase your feature/topic branches on top of master and then merge the
feature/topic branch back onto master, enabling a fast-forward merge.

~~~
austinjp
Is this a common workflow? Googling suggests almost religious feelings about
this.

~~~
woodrowbarlow
it comes down to whether you want your version history to reflect the true
version of development's history (merge), or a simpler, doctored version of
history which reflects the final deliverable (rebase). advocates of the
latter, myself included, argue that it eliminates noise and tells all the
story that needs to be told -- and that the original history can be preserved
by not deleting the feature branches. others argue that changing your parent
commit is dangerous and occlusive.

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-...](https://medium.com/@fredrikmorken/why-you-should-stop-using-git-
rebase-5552bee4fed1)

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.

------
mxuribe
I'm a matrix - really via riot client - user, but never used zulip...Can
anyone cite 1 or 2 big benefits of using zulip over matrix clients? I'm
genuinely curious.

~~~
mockingbirdy
[https://zulipchat.com/why-zulip/](https://zulipchat.com/why-zulip/)

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.

------
detaro
last large discussion of Zulip (6 months ago):
[https://news.ycombinator.com/item?id=16863675](https://news.ycombinator.com/item?id=16863675)

------
Polyisoprene
We looked at it briefly, but the number of components make it look more of a
tech demo than a product meant to be installed on-prem.

Redis, Postgres, Rabbitmq and Memcached just to run a chat?

~~~
TheDong
> more of a tech demo than a product

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.

~~~
wmf
IMO it would be nice to have scaled-down implementations of caching, queueing,
etc. for "small" installations of self-hosted apps to reduce the number and
complexity of dependencies. But first there would have to be a market for
self-hosting.

------
akshayn
As I commented here [1], one of my biggest issues with Zulip is that the
mobile apps don't have a "jump to most recent" feature, and whenever I open
the app I have to manually scroll past hours (or days or weeks, since I
dislike opening the app so much) of old conversations.

Has this been fixed/improved?

[1]
[https://news.ycombinator.com/item?id=17623592](https://news.ycombinator.com/item?id=17623592)

~~~
borisyankov
The mobile app does a "jump to the first unread message" by default, which is
the same behavior the web app follows. If you don't want to read through all
the messages in the current stream you can press "Mark as read" and then the
app will be jumping you to the latest messages. Would that improve your
navigation flow in the app?

------
woolvalley
How does it compare to mattermost?

~~~
sien
Exactly.

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?

[https://mattermost.com/](https://mattermost.com/)

~~~
tiles
Have you tried out Zulip? You may find the user experience pretty compelling.
It's an entire alternative interface to the slack or IRC-style of chatrooms,
and it's OSS and documents how to make it containerized.

~~~
sien
Not yet.

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.

------
msie
The one good thing about not having an on-prem Slack is communications after
your company network goes down.

~~~
borski
The one good thing about having an on-prem Slack is communications after the
Slack network goes down.

~~~
qiushihe
That's why you should run both.

~~~
bachmeier
Or print out all your conversations.

------
mahesh_rm
Anybody knows why this over rocketchat?

~~~
demonshreder
Zulip has a thread based Instant messaging model which helps facilitate
multiple different conversations in the same channel without losing track /
context.

More on their homepage - [https://zulipchat.com/](https://zulipchat.com/)

~~~
jfrankamp
What is the advantage of threads over just more specific top level channels.
e.g. in their example why not #annual-summit-name-tags etc. One immediate
thing slack does wrong is it makes channels too hard to make and destroy and
leave and join, but if that was fixed... What is the advantage of the nesting?

~~~
aidenn0
zulip ends up being a bit like e-mail where you can add people to threads and
they immediately have the history. I've used mattermost, not slack, but that
basic model fixes a lot of issues I have with mattermost.

~~~
jfrankamp
A more specific slack channel (and I assume mattermost channel) is a thread
that you can add people to any time and they will immediately have history. Or
put in the inverse, a Zulip thread that is too general is a channel with
information overload and becomes useless. Does the nesting have intrinsic
value over simply more top level channels?

~~~
aidenn0
Mattermost has threads inside channels as well, but they end up underused
since posts need not be to any specific thread.

The idea is you subscribe to a channel, but then any post to the channel needs
to also have some sort of logical subject.

~~~
tabbott
Right, in my view it's important that every message have a topic/thread. The
reason is that you spend most of your time/effort in a busy team chat tool
consuming other people's messages, and that flow is a lot more efficient if
you don't have a giant "catch-all" bucket of unthreaded messages about
fundamentally different things to wade through in order to find what's
important to you.

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.

------
grizzles
Judging from the zulip.org server it looks like there is a need for a
chronological topic decay feature.

~~~
tabbott
Zulip founder here; I'm curious why you think that?

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.

~~~
mehrdadn
Hi there! I just started using Zulip (first-time user) looking forward to
migrate off Slack and unfortunately I've been really disappointed. In Slack I
can just load the website and begin typing into whatever channel I'm at (or
use 1 click to select the right one if it's not the current one). In Zulip, it
seems there's been a deliberately goal of explicitly designing it to be
excruciating painful. For some reason Enter doesn't work by default (in which
chat system is Enter an unfamiliar command for sending?!), and then I _always_
have to press 'R' or click something to reply to (which often takes multiple
clicks and several seconds)... why make things deliberately
complicated/painful without even an option to turn off this 'feature'?

~~~
rishig
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.

In any case,

* You can enable "Enter to send": [https://zulipchat.com/help/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.

~~~
mehrdadn
Thank you for the reply!

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?

~~~
rishig
Got it, thanks for the concrete examples.

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.

~~~
mehrdadn
> 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 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?

~~~
rishig
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.

------
Aeolun
Am I the only one that just can’t stand the way zulip looks?

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!’.

~~~
seedie
The first time I saw it I had the exact same reaction. Using it I encountered
two things:

\- 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 ;)

------
nh2
For me the most severe lacking feature of Zulip vs Slack is that you cannot
mark messages as unread.

------
devy
New to Zulip. So is it sponsored by Dropbox now after acquisition of Zulip
Inc.?

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).

~~~
tabbott
Yikes, we haven't updated my blog bio in a while. Fixed to remove the
confusing reference to Dropbox (which no longer has any formal involvement in
Zulip); [http://zulipchat.com/history](http://zulipchat.com/history) has
further context for anyone curious.

------
shin_lao
We are heavy Slack users. We tried Zulip. No one in the team liked the
ergonomics of Zulip and how difficult it was to integrate. Just for threaded
discussions we felt the switch was not worth it. It didn't stick and we stayed
in Slack.

~~~
Aeolun
Might want to look at [https://twist.com/home](https://twist.com/home)

It seems a bit like a slakey zulip to me, though I haven’t had opportunity to
use it yet.

~~~
zingmars
No self hosted option :(

------
amelius
As someone who follows technology closely, I find it a bit frustrating that
chat is making such little progress, and that for our communication we've
essentially moved from federated email to silo-based chat solutions (which is
hardly a feature), and lock-in that comes with these. How is "IT" going to
save the world if we get stuck like this as a profession? I suspect one
problem is that at universities there is no credit to be earned from coming up
with a chat protocol that can serve us the coming decades, and hence we're
stuck with solutions from corporations and their inherent problems ...

But of course that's not to say that there is anything wrong with the quality
of the product being promoted here.

~~~
brylie
For what it's worth, Zulip is one of a few projects to support federated chat.
From the linked document:

"Zulip now has an IRC bridge powered by matrix.org"

~~~
amelius
Yes, they probably support email as well, that's not the point.

See:
[https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...](https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish)

(not saying this is the case here, just that it shouldn't be a concern)

------
Nux
We looked at it, wanted to like it, but for self-hosted there were problems
with app notifications, something that plagues most self-hosted hipchat
replacements (except for xmpp).

~~~
tabbott
When did you look? [https://zulip.readthedocs.io/en/latest/production/mobile-
pus...](https://zulip.readthedocs.io/en/latest/production/mobile-push-
notifications.html) has been available for over a year, so self-hosted has the
same notifications experience as Zulip Cloud.

~~~
Nux
It relies on Zulip's central notification service, so not entirely self-
hosted.

~~~
zingmars
At the bottom of that link[1] you can find instructions on how to send
notifications directly from your server, but it involves recompiling the apps
(which is hardly Zulip's fault).

[1] [https://zulip.readthedocs.io/en/latest/production/mobile-
pus...](https://zulip.readthedocs.io/en/latest/production/mobile-push-
notifications.html#sending-push-notifications-directly-from-your-server)

~~~
Nux
Yes, this was covered under our evaluation, I appreciate it's not your fault.

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.

~~~
ahofmann
What zingmars wanted to say is that it's not possible to have "self hosted"
notifications without recompiling the Android and ios Apps.

------
rob-olmos
If anyone has tried G Suite Chat, it looks like they've added "threads" at
some recent point but the UX has some ways to go.

------
Hydraulix989
I also recommend RocketChat

[https://rocket.chat/](https://rocket.chat/)

~~~
rocketChat
Depends on your security requirements:
[https://github.com/RocketChat/Rocket.Chat/pull/10793#issueco...](https://github.com/RocketChat/Rocket.Chat/pull/10793#issuecomment-395195356)

~~~
Hydraulix989
What is your affiliation with RocketChat?

------
kossmoboleat
How well does the Hangouts integration work? I found it involved too many
steps when using Hangouts in Slack

~~~
tabbott
It's pretty simple: There's a button you can click at the bottom of the
compose box that generates a new Hangouts video chat link; once oyu send your
message, users can click the link to join.

------
thenaturalist
Title is somehow linking to the blog instead of the actual product page
([https://zulipchat.com](https://zulipchat.com)).

~~~
Mononokay
Because it's an announcement of a new version. Not that hard to figure out.

------
jimmy1
I mistakenly assumed there wasn't a paid offering.

So it's becoming clear that the only revenue model going forward is open core
model.

~~~
wmf
It looks like the paid edition of Zulip is the same as the open source version
so it's not open core. Of course if Zulip becomes too popular then we may see
AWS GroupChat followed by a license change...

~~~
bradknowles
AWS already has Chime. They don’t need anything else.

------
Jumziey
Whaaat!? I who always thought irc was the on-prem Slack alternative. Its a
pretty cool thing that recently got created (around 1988). Try it out! Will
blow you mind straight out of the water tbh. There's even some public chat
rooms you can hang around in.

~~~
wild_preference
IRC: No code-block formatting. Can't even receive messages when you're
offline, out of the box. No message delete/edit. No built-in file hosting,
must upload elsewhere and link it. No drag-and-drop. No real ergonomics in
general. Way behind on community-building/-management features. Only
particularly liked by the sort of person who considers tweaking their .conkyrc
as a Friday well-spent.

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.

