My research group (at MIT) also uses Zulip for messaging.

While I agree with everything jremmons said (hi john), it's important to note that their mobile apps are so bad that they're basically unusable - there's a particularly aggravating bug in the iOS app where if you don't open the app for a while, it forces you to load and scroll through days of messages to read the most recent ones.

hi akshay :)

> every message you send has to be sent in a topic. ... Ever have a situation in Slack where two people are discussing something in a channel instead of using a thread or DM? That isn't possible in Zulip.

After some short period of playing with Zulip with a colleague of mine I found this feature to be confusing, at least for new users: it is way too easy to disregard the concept of topics and start writing to the random topic that happens to be selected in user's client atm, and in the end the conversation mess keeps being a (slightly rearranged) mess.

This is where the topic editing feature comes into play; any user can change the topic of a message sent recently, and if someone posts something in a wrong topic, it can be moved to a different topic.

Also, after a while this paradigm grows on you and by forcing you to think of a relevant title for your conversation, it forces you to have more cohesive conversations in my view.

And, lastly, it is possible to send messages without any topic (it defaults to (no topic)). :)

I’ve been wondering about this. Instead of topics, why not use hashtags? I know in Slack the hashtags indicate the channel, but they don’t need to. So instead of having set topics, you could just add a tag to messages to indicate the topic.

When a user is forced to make a decision on something like ‘topic’ just to send a quick message, you’re more likely to get randomly assigned, meaningless topics. Random hashtags, on the other hand, are no big deal. Because you have to actively search for the ones you want.

This has been the paradigm since Web 2.0 and it seems to have worked pretty well.

Random topics are no big deal in Zulip either. You can either a) edit the name of the topic at any time if needed or b) create a new topic as topics are cheap

Slack channels (and Zulip streams and HipChat rooms) are not "hashtags", they're IRC channels in modern form.

When a user is forced to add a tag for a message, you're more likely not to get anything tagged and therefore decrease the utility of search.

So you're going to start auto-assigning a tag, maybe based on their last message, which brings you back to channels / topics / chatrooms.

That's the approach that we take in Braid chat: https://github.com/braid hat/braid

Works well, although some people are put off by the similarity to Twitter #sigh

I'll also add that one of my favorite features is the vim-like keyboard shortcuts. It makes navigation very quick, and I love being able to easily quote an entire message by just hitting `>`. The full markdown and keyboard shortcuts are fantanstic to have.

Slack can do multi-line comments too.

How does Zulip handle file uploads and images?

Supports inline linking to images on the internet like: [caption](url-to-image) and also supports uploading files.

Do feel free to give it a test drive on https://chat.zulip.org on the stream `#test here` to get a feel for it. :D

> file uploads

Good question. Uploading an image from slack iOS app takes forever and most of the time don't succeed.

It's not a network issue since other apps manage just fine.

So would it be correct to summarize zulip as real-time email?

Google Wave was the real-time email, remember that? me neither.

I wonder what would have happened if they used the tech to build a chat application instead of an email-killer.

I loved google wave -- it was great and ahead of its time. I think it was a major mistake that google let it go and that the apache wave foundation never got it going. it is too late now but really a greatly missed opportunity.

It was definitely ahead of its time. It would be interesting to do a reboot with much better chatbot technology (driven by all the advances in NLP).

(1) It wasn't.

(2) It tried to be an all-in-one comm platform, and because of that it excelled in none of what it tried to do.

(3) Poor UI performance was the death sentence of it. If you can't use it fluently, it's not good for real-time. Poor UI design did not help, on top of that.

It was an interesting experiment, but not all experiments end up with a successful product. I hope the ideas will be unearthed at some moment and reused with a greater effect.

They used the tech to build Google Docs.

Real-time email is a contradiction in terms, as (at least for me) being asynchronous is one of the main defining features of email. Essentially any chat app, from IRC to Slack, can be called "real-time" email. To me, the phrase "real-time email" sounds like calling a submarine an "underwater car".

IMs hit the sweet spot between fully real-time (like the phone) and fully async (like paper mail).

The UI is built for efficient real-time communication, but the underlying data model (the log, notifications, statuses, etc) allows for very easy async communication.

I think someone could make a great product by just adding IM-like UI features on top of an existing email backend. Email is pretty fast these days to work as mostly-instant communication.

I agree! Check out https://delta.chat. I use it every day for emailing. Subject lines are the ellipsized first words of your body and every message is a new email.

Zulip is closer to being "real-time email" than Slack is, but I wouldn't call it real-time email.

slack threads suck I might look into Zulip though, this seems interesting. Having subchatrooms compiled into one giant chatroom is also how I organize my gmail as well. So you have the option to look at individual rooms or just one room to see the same content

I wish it had color text input support. At my last job, they were looking to replace IRC with RocketChat, and that was a big let down. I even submitted a PR for "Colored Markup" (https://github.com/RocketChat/Rocket.Chat/pull/8639/commits)

What would you be using coloured text input for?

The use case at the last job, was that I had an IRC bot that had a lot of stuff to deal with support stuff, like DNS configuration for the Hosted Exchange offerings (2010 and 2013 were offered), and it would do colored text for good and bad configurations. Just made it easier to point out the issues.

what were some if the big problems with rocket chat?

Well, IRC clients allow for more customization for the end users, RocketChat - there was very little. The dev team didn't want to add hacks on to it and would only update when RC would release a new version.