Hacker News new | past | comments | ask | show | jobs | submit login
Zulip 2.0: Open source team chat (zulip.org)
310 points by tabbott 23 days ago | hide | past | web | favorite | 96 comments



We use Zulip for xi-editor and related projects, and I am very happy with it. I find it helps us have real discussions, as compared to other types of forum (and I've tried a bunch).

Two features in particular make me feel it's helping me rather than just trying to soak up my time and attention. One is the "topic" organization, which is especially useful for conversations that span a length of time. A serious downside to HN and Reddit is that discussions flare up for a day and then become dead. Topics solve that, and have the added advantage (compared to, say, IRC) of being linkable, so I can point people to an existing discussion.

The second is the unified chronological display. This lets me catch up quickly with lots of discussions at once, as opposed to digging through a page for each conversation and then sifting through timestamps to find the new comments.

Disclosure: none. I'm just a happy user, and it's generously available for free to all open-source projects. I have no connection to Zulip or Tim, other than being fellow Recursers (which is probably how a lot of Zulip users get hooked).


Linkability is a really big deal. You can get it with IRC if you keep public logs, but getting a link is definitely harder than if you have a fully-integrated system like Zulip, as there’s no standard way for the client to sort it out.

At FastMail with our group email system Topicbox, we put a link to the archives for the current email in the mailing list footer, and that’s the favourite feature of quite a few of us in the company, and we’ve heard similar from our customers too. (Not sure why Mailman doesn’t do this, it’s super useful.) This gets around the need for a single frontend. Something IRC-like could work that way if each line sent included a URL, e.g. in JSON {"speaker": …, "url": …, "time": …, "text": …}. I have no idea at all if the likes of Matrix can or do work that way.

You get bonus marks on a feature like this if it includes meaningful content in the URL, e.g. Zulip’s URLs, although a tad ugly, include the stream (a slug) and topic (slightly weirdly encoded rather than slugified, but still present and readable). That way I can look at a URL and have a fair idea what I’m getting myself into. (URLs are definitely UI.)


Here's a link to a specific matrix-message: https://matrix.to/#/!QtykxKocfZaZOUrTwp:matrix.org/$15515574...


> Not sure why Mailman doesn’t do this, it’s super useful.

I believe this is because mailman doesn't have an integrated archive - it would have to ask hyperkitty (or pipermail etc) for an url to include in the outgoing message.

I'm sure it could be changed, but probably reflects that mailman is "mail first", for better or worse.


All it needs to work is a field for a URL template, and for the archive system to have sane URLs. Pipermail URLs don’t correspond to anything in the email, so the simplest imaginable integration would entail an additional entry point like /lookup?list-id={listId}&message-id={messageId} which would redirect you to the page for the right email.

Granted, this is really bad when compared with an integrated archive, but it makes it at least possible. You could easily then go on from there to automatic configuration for specific archive systems.


URL isnt necessary just a UUID / GUID as part of the message structure that the server then maintains track of. But I dont think most servers care about logs in a structured way.


An ID for a message is sufficient iff there is a defined, deterministic way to turn it into a URL. In the case of an IRC-like protocol, that would mean that you needed a defined URL structure, or a defined way for the server to give a URL template to the client.


> I find it helps us have real discussions, as compared to other types of forum (and I've tried a bunch).

Have you tried a modern forum, like Discourse? I'm trying to understand why many open source projects opt for chat platforms instead of a forum. Why are you resignating public and search engine accessible discussions?


Overall, I find Discourse really annoying. It has some good stuff in it, but it just tries to be too clever, replacing standard techniques that play well with web browsers with its own magic that is simply nowhere near as good. Its lazy loading story, for example, is extremely weak. (I don’t know if it’s better with 25ms latency rather than the 250–350ms an Australian will always get on such things which are invariably hosted in the US, but I don’t expect it’ll be good even there.) Just load and render the entire thread, please, and then don’t hijack Ctrl+F.

Discourse is also very wasteful of space for anything but long-form prose: a single line of text is 180px high (in other words, a typical screen will never under any circumstances fit more than five comments on the screen at a time), and a single-line quote from someone else adds 80px. Compare discussions here on HN with Discourse. I’d much, much rather work here. (Yes, their purposes are somewhat different, especially as regards ordering; and applying the HN structure to longer-term discussion would require changes of some form, because it wouldn’t work if you just took it verbatim.)

If I had infinite time, I’d write a leaner frontend for Discourse with much less magic and much less wasted space.


I have used Discourse quite a bit, and it was a top consider when we were looking for a new platform.

Public web archives are a goal, and either we'll deploy a bot to publish them, or I've heard rumors this feature may be added to Zulip itself.

In the meantime, it's kind of nice not having everything immediately publicized. We've had (knock on wood) exactly zero problems with spam users, even though it's open to everybody with a Github account. I'm also (if temporarily) enjoying the freedom to talk a bit more intimately, for example I'm discussing a major project I'm considering taking on.


Public archives is definitely on the Zulip roadmap; much of the preparatory backend work for supporting was merged last year.

One thing I'd be interested in feedback on is how folks would feel about an ugly/janky version? There's a few different versions we've talked about:

* Being able to use the main Zulip user experience, with "public user" data (no unreads, can't send messages, etc.). This would be best as an actual browsing experience.

* Having a totally new webpage that's mostly just HTML+CSS (better for search engines) similar to our digest emails.

Possibly we'll eventually do both, but I'd love feedback on which of these open source projects care about the most.

(In any case, it'd be configurable at the stream level, so you could have some but not other streams that are public in the organization be publicly archived; we already have the data model for doing that).


Of these two, I find the second more appealing. The main use cases I have in mind are linking discussions from issues, and in general creating a permanent record of the work we do (our IRC logs got lost, I should have been on the ball to preserve them).

For people who actually want the Zulip experience, I have no problem just asking them to sign up for real. Since we have open signup based on github login, it's a pretty small barrier.


I think (2) sounds more useful too. You may also wish to consider a 3rd option: a machine readable export format (XML?), which would allow users to make their own human-readable archive formats.


That's already easy to do with the Zulip API.


I think people feel more comfortable in chat than a forum. People often feel hesitated to ask simple questions on forums thinking it's stupid. Plus forums take too long to reply.

It's often better to have both, I think.


I agree, I actually built that, I mean, a chat + forum at the same time. And it works in the way you said: people post quick informal questions in the chat, and longer more "serious" questions in separate topics. https://www.talkyard.io


chat(slack etc) is real-time basically, forum is not.

the best will be chat+forum, and support mailing list style digest, also support post-by-email


Then you might want to check out Talkyard, it is chat + forum. https://www.talkyard.io (I'm developing it). A bit like a Slack, HN, Discourse hybrid. Post-by-email is planned.


Looking good, but please, don't make me click on the small area that is the title of a post to see the content.


Ok, thanks for the feedback. (You had in mind the topic titles, in the topic list, right? And you'd prefer the text excerpt, below a topic title, to also be clickable and link to the topic, right?)


Congrats on finishing this.

A suggestion for the Zulip team: email is the hardest part of setting up any self-hosted solution, and Zulip is no different. You covered a lot of bases in your email section: https://zulip.readthedocs.io/en/stable/production/email.html

However it's still too difficult for many people to setup an account with an ESP, get the SMTP creds, and configure Zulip to use it correctly. It's a big step for people newer to self-hosting. I would suggest meeting somewhere in the middle for those people, by offering a paid self-hosted tier that handles some of the "harder" stuff for them. You can see how the popular 3CX phone system does this for inspiration: https://www.3cx.com/docs/fqdn-management-allocation/

All 3CX accounts receive a FQDN and confirmation emails are routed through this managed service, no configs needed. You could charge perhaps $80/yr for this tier, so customers wanting to host their own data can do so, but have SMTP and DNS managed for them by providing them with a Zulip subdomain, like Slack does.


Interesting idea; it's not something I'd thought about. I definitely figuring out what SMTP server to use is the hardest part of Zulip server setup, and I had believed there was nothing we could really do to make it easier. I guess the concerns I'd have are:

* Do people running on-premises actually want us to be an intermediary for all the emails their Zulip server is sending? I would imagine if they were happy with that, they'd be happy to just use Zulip Cloud.

* How does 3CX avoid this service requiring them to do a bunch of anti-spam work?


- If the emails are only account setup or forgot password related, I don't see much issue. If you send daily digests or chat recaps, perhaps it's a bit much to assume this responsibility.

- 3CX has a footer in each email: This email was sent from an 3CX SMTP Relay Service. If you suspect the service has been used unlawfully and/or outside the scope of delivering 3CX Phone System related emails, please file an abuse report here: https://www.3cx.com/smtpabuse

How much work this requires on their end to keep clean is unknown, but definitely a concern as well.


For 1-click deploys, have you considered packaging for cloudron? It has other chat apps and it has automated email send/receive as well.


It looks like they are based on Docker; I imagine they could use https://github.com/zulip/docker-zulip. It seems like Cloudrun packages other apps, not the other way around?


I do believe that the SourceHut project is investigating ways of simplifying the process of self-hosting email, for the purpose of using it to power a self-hosted forge platform. I feel like there's a decent chance of a large overlap in needed features and goals. The SourceHut folks are highly reachable on Freenode in #srht and other places.


So much better than Slack. It's crazy to me that a never-ending stream of chatty one-liners is what people think as "productive"

Experiment for slack lovers: Start talking about something in a channel with ~20 people. Have another use try to start another conversation in the same channel.

What happens? Garbage. Chat is not how work gets done. Or how knowledge is transferred and, most importantly, retained.


We make heavy use of threads in slack for anything serious at my work. #general and #random are a mess of course, but that's kinda their point.


If they worked better we would too. But you can't have threads without also stopping people from throwing one-liners into an ongoing channel. You need both.


I have been using Zulip for a long time now. One of the complains I get too often is that design is not very appealing compared to slack or discord. Though it's very fast most people just don't care, and hence it's hard to convince a team. Are there any plans for UI changes? I wish you guys did.


Yes, there are several major things planned (in addition to the fact that every release touches dozens of smaller UI things; you should see what the Zulip 1.3 settings UI was like!). A few notes:

* There's active work on replacing the top-navbar/search area with something nice and clean that displays the stream description, number of subscribers, and other details.

* Our current visual density is really good for power users, but . zooming to 110% makes some people a lot happier and makes Zulip look more modern. We're working on changing the default visual density to look more like that, while leaving the current styling as an option for power users.

* You should try the night theme (in "display settings") -- a lot of folks who are picky about design prefer that one.


Thanks for planning on leaving a dense option in. I much prefer UIs with less whitespace and am saddened by the current trends in this area. I really like Zulip and its UI, thank you and everyone else for creating it!


The UI was what kept us from Zulip last time we evaluated chat at my employer. When maximizing the window not even half of it was covered by the actual chat but by meaningless white space on both sides. We could not figure out how to change this either. Is this addressed with the new release?


Thank you for voicing this concern. There is something satisfying at a deep, almost visceral level about Slack's UI/UX (whatever else you think about it's ability to search/organize information). As someone looking for alternatives, it makes the transition seem very jarring because almost nothing looks as good.

I'm trying to convince a team to go to Zulip but the design adds an extra roadblock which makes it just that much more of an uphill battle.


I have used Zulip in the context of a well-tooled coding/debugging workflow and I can't think of anything it didn't do that would have been useful. Nice integrations with JIRA and other coding oriented tools. I didn't like the Android UI, but that was a minor point at the time since I'd have to get out my laptop to address an issue anyway.

I use Slack for some projects currently, and it's pretty good most of the time, and brilliant some of the time. The UI is slick AF but it stumbles some places, such as spreading UI verbs around the menu bar, a pop-up menu, and a button bar without having the menu bar replicate things like accessing the pinned items pane, which is only a tiny monochrome button in the tiny button bar. IOW it's slick until it isn't.

Overall I'd say if you add Zulip to your task list for setting up a coding workflow you won't regret it. Slack is a little easier to get non-technical people on board, especially if they are more smartphone UI oriented, but Slack is no bed of roses, either, when it comes time to explain to users when channels, threads, topics, stars, and pinning are useful.


We’re thinking about un-slacking our team. We’re utilizing Airtable and Atlassian for more contextual discussion but want to keep a chat system around - especially as a 100% remote team. Rocket.chat has been our planned destination for some time now, but we have looked at Zulip in the past as well. Can anybody compare and contrast Zulip vs Rocketchat, or link to something that does? I’m especially interested in if this new release changes that equation in any significant ways.


I was part of the un-slacking task force at my previous job. We gave Rocketchat a test run, but ultimately decided it was just a less-polished Slack. We also took Twist for a spin, which I really enjoyed. However, our support department relied too much on real time chat to abandon it completely. Zulip was a really nice compromise that I highly recommend.

If every Slack post had to be either the start of a thread or a reply to a thread, you'd basically have Zulip. The hardest part is conditioning everyone to use good thread names and not establish topics that are overly broad or narrow.


I think better would be just to try both and let the team decide. 1-2 weeks each.

We have migrated from HipChat and 1st we tried was Stride then Zulip, where we stopped.

Main complaints regarding Zulip were (are) Windows client not stable, UI a bit clunky.


Since you mentioned 100% remote, don't you think Zulip has advantage over other chat apps because of the asynchronous nature of conversations? Zulip team is also fully remote. We have core team members in North America, Europe and Asia all using solely Zulip for communicating. We don't do video/audio conferencing. All most all the decisions are made via text chat thanks to the wonderful asynchronous nature of Zulip threads :)


We use Zulip for Code Shelter (https://www.codeshelter.co/, an OSS maintainers collective) and I love it. It's so easy to keep track of everything, and I love how it encourages you to write long-form replies rather than the Slack-like one-offs. It feels like a cross between chat and email, with the best of both worlds.


Neat! But no e2e encryption, so I'm going to have to stick with Matrix. Interested to see how this project progresses, though. Looks great, and active.


So, philosophically, as a former MIT cryptography grad student who spent a lot of time in Ron Rivest's office, I'm unwilling to offer a cryptographic guarantee like "E2E encryption" if it doesn't actually provide the security guarantees that any reasonable user would expect when they heard that phrase.

Zulip encrypts all content in transit using HTTPS, which protects against a pretty wide of potential attacks to the privacy of one's messages. We put a lot of effort into ensuring messages aren't sent to the wrong users (one surface-level detail here is that our backend codebase has ~97% test coverage; which becomes 100% for views, validation, and other security-sensitive code).

The big thing that these techniques don't protect against which E2E encryption is supposed to solve is a malicious/compromised server accessing message content. But I'm also not convinced there is a viable solution supporting desktop+web+mobile+terminal apps that can prevent a malicious/compromised server from getting access to message content.

Just to highlight one of the issues, if you're using a webapp, the server itself is what tells your browser what code to run. So, if the webapp can display decrypted message content in a browser, a hacked server can just deliver JS code that causes the browser to fetch every single message of history your browser client has access to and send them back to the server unencrypted. I've thought at times about whether a trusted browser extension could help, but I don't think it can. I imagine the various "E2E encrypted" apps address this issue by just not offering a webapp.

Even if one were willing to abandon having a webapp for this feature, the really hard problem with doing E2E encryption is key storage and distribution. What process do you need to use to move your secret key between different devices safely (or do you just lose access to your history when your phone dies)? How do new users who get added to a stream get the secret key for that stream? Maybe there's a Keybase integration that would solve this (I actually have exchanged a few emails with the Keybase team about this concept).


> Just to highlight one of the issues, if you're using a webapp, the server itself is what tells your browser what code to run. So, if the webapp can display decrypted message content in a browser, a hacked server can just deliver JS code that causes the browser to fetch every single message of history your browser client has access to and send them back to the server unencrypted.

If a native app is compromised, you are screwed all the same. I don't see how the delivery channel makes a difference -- the server serving the web client doesn't necessarily have to be the same one that's relaying the messages...


Well, theoretically, you could use a signed version of a native app from a distributor you trust (or build it yourself after inspecting the code, or whatever).


e2e encryption is an anti-feature for many. In places where an internal team chat is needed (i.e. companies), the ability to log and audit conversations is a requirement. I agree it might be nice if it was optional, as long as it can be disallowed globally by a server-side setting.


It's sad that electron app is now only way to get a desktop client this days.


Zulip also has a terminal client.


There are pretty serviceable native GTK and Qt Matrix clients nowadays.


Does it have read receipts now? They were one of the reasons why we picked Matrix over Zulip for our war room chat at work.


Not yet. https://github.com/zulip/zulip/issues/3618 is the issue for it if you'd like to follow it.


Oh god, that's terrifying. Then I'll see "Why haven't you read my message? Why are you ignoring me?" all the time :(.


Still not quite as bad as the "I _know_ you read my message and are deliberately ignoring me."


How hard is it, currently, for an ordinary technical but non sysadmin person to host Zulip on a VPS? say, for 30 users. is the process very complex? is it a lot of work?


Probably one of our users can better to attest to this than I can, but it's really easy for someone with that background to maintain. For installation, we've put a ton of effort over the years into making all the commands Just Work if you copy-paste them, adding custom error messages if you run something as root you shouldn't, etc.

And we put a ton of effort into making the upgrades, even for major releases like this, be a single command that Just Works for almost everyone.

I know this because I personally respond to every single report of issues installing/upgrading Zulip and have been making changes (even if the issue is basically user error) after most of them to help ensure they don't happen again for a few years now.

That said, if you don't want to deal with doing that work, Zulip Cloud is very reasonably priced for situations where all the users are employees (compared to payroll, it's effectively free) and for other use cases, we have steep discounts (e.g. free for open source, a huge discount for education, etc.).


I set our juniormost sysadmin to install Zulip. He took a couple of days to read through the docs, then did it in an afternoon.

Adding custom keywords -- Zulip calls them linkifiers -- took a fair amount of time, but we have about 25 of them and few of them resembled each other much.

Since install day, it really hasn't required much maintenance.


Hi Tim,

I just upgraded to 2.0 and was so damn impressed with upgrade code. I run Zulip in a VM with an NFS root, and hit some random NFS bug that resulted in this error:

... Found existing installation: cryptography 2.3 Uninstalling cryptography-2.3: Successfully uninstalled cryptography-2.3 Could not install packages due to an EnvironmentError: [Errno 16] Device or resource busy: '.nfs00000000016cef5200000f9e'

... `pip install` failed; retrying... ...

Then it succeeded, all by itself.


This is so awesome to hear.


As a test about 6-7 months ago I set up a Zulip server on a VPS to test it out. Because it was a test I can't speak to scale, upgrading, or maintenance, but I would hope most any VPS would easily support ~30 users. The install process was unmemorable. I just had another look at the docs because I couldn't remember the process was. This is probably the best endorsement that can be given because the worst-case would be hunting down dependencies and having to compile stuff and tweak config files and it taking up most of a day or two. Instead, it was probably less than an hour from going to my vps' website to provision a new server to logging into Zulip from the client on my phone. I don't see any reason not to try yourself.

I'm not sure of your proficiency, but if this is a public-facing server you may want to either go with their paid service or hire someone to do the initial setup and walk you through maintenance since there's more to securing a server than just installing and getting it working.


I wonder how the IRC bridge works with regards to threading.

Does it merge multiple consecutive messages from a single user into a single Zulip message?

Are all replies from a channel just a never ending thread that goes on and on forever?

I might have to try it to find out.


I believe it's the second :). (All replies from a channel go into a never ending thread that goes on forever.)


Tangent about threads and Slack culture.

I have noticed that there are people who either purposefully, or unconsciously, do not use threads. They litter the stream by making sentences instead of paragraphs. What I don't understand is how could Slack not see this as an issue?

From my individual's perspective, I don't get the idea of chats as a one liner when topics should be contextualized via threads.


I've heard Zulip is much better about threads, but in Slack there are some annoying things about them. Everything is crammed into the sidebar, so reading log snippets suck. Also, I noticed people will often post their initial message, then a @here with slightly more info in the same channel. I'm not sure where to begin the thread from. I haven't been able to intuit the rules for alerting people or uploading things like images into a thread.


Zulip (and Zephyr) is indeed much better for threads. You can actually find them to use them later. In Slack, it's more like a side-bar, instead of a topic that you could come back to later and anyone throw into.

Whereas I used threads all the time in Zulip, they are really not great in Slack, and mostly just useful for reducing noise for off-topic discussion.


I could be misremembering, but I think Zulip let anyone attach a message to a thread, not just the original writer (I think because it identified threads by text match).


FYI for slack I see a button for "All Threads" or "New Threads" at the top of the left sidebar. Here you can see all your threads in full width glory (instead of crammed into the sidebar which I agree is annoying).


You're right. I don't know if this is a bad habit on my part, but I generally avoid "All Unreads" and "All Threads" because I'm focused on one thing at a time and want to leave unaddressed things unread until I can focus attention on them.


I run a Discord server and this drives me mad. Since Discord doesn't have threads, everything is in the main chat. I know for a fact I'm going to die by being buried in notifications because people can't wait 1 minute to type a response, they need to send each half sentence on its own. Meanwhile, all of my statements appear late because I've taken the time to put the entire thought into one message.


> What I don't understand is how could Slack not see this as an issue?

Similar issues exist in email communications. I feel like these are really more just issues with the person's ability to communicate. Perhaps the technology can help, but I'm having trouble imagining how.

Unfortunately, I've tried to educate some of these types of users that I know (e.g., showing them that Slack's formatting options exist, are easy to use, stop quotes from randomly getting turned into smart quotes), but IME communications skills are one of the last things people are willing to accept feedback on. I find it often just gets acknowledged "oh, that's great, thanks!" and then promptly ignored (no change in behavior).


> They litter the stream by making sentences instead of paragraphs.

You may find this old conversation amusing:

https://news.ycombinator.com/item?id=11239614


iirc there is a server side setting to disallow messages without thread.


Is the Linux client native? Discord and slack have > 1gb footprints bc they're just web browsers and its awful.


I've been looking at solutions like Slack/Zulip/Rocket.chat for a real-time customer-support/chat system where the user would chat with my team via a chat interface on the web-app while members of my team would reply via the chat solution on our end. This way we'd keep all these customer convos in the same place where work-chats happen.

Does anyone know whether Zulip has an integration or some trick to achieve that? I'd rather not have yet-another-system in place just to accommodate chats with customers.


We really like Zulip, but one major complaint is the delay/slowness of notifications on mobile apps. We are not self hosting it, but using the official zulipchat domain.

Is this a known issue?

It is a problem, because we want to use Zulip for alerts too and delayed notifications means slower reactions.


We did recently improve how notifications are delivered on Android, about 1-2 weeks ago. Keep an eye on if you are still having issues, I hope the delay is resolved.


Thank you! I will pass it on.


Zulip is definitely the best of the open source Slack alternatives. But having to think of a subject for every single message is just ... well, it's a newsgroup, not IRC.


This is a common confusion from folks who haven't really used Zulip. You don't need to think about the subject for every message, because 95% of messages you send are replying to an existing message/conversation, and you don't need to think about topics to do that.

For those messages where you are effectively changing the topic of conversation, in Zulip, rather than starting your message with "On another note," or a similar phrase to communicate that you're about to say something unrelated words, you instead just send your message to another topic.

And if there are multiple conversations happening at overlapping times, Zulip's model often ends up saving you from having to say "@fred yes" in your reply to indicate which question you're answering "yes" to, because it's obvious from the structure.

You can argue it's slightly more work for the person sending a message to type a topic when you bring up something unrelated, but it's certainly not much, and it's only relevant to a small fraction of messages that one sends. Whereas what Zulip's model saves your organization is every one of the N users who can have to read the conversation needing to spend much more time and mental effort in order to understand what conversation(s) happened while they weren't looking at chat and whether there was something that needs their attention.


I haven't found this a problem. We tend to just have general topics, like very often the "what's everybody working on this week" topic.


I am a newbie in this area, but could Zulip use machine learning to come up with a relevant subject or topic name? I am not sure how it would work though, since it might be required BEFORE you send messages, and you may not want to change it frequently after that, because people should not memorize the changes all the time, it would backfire I think.

But still, does it make sense in any way that I cannot think about right now?


you don't have to use a topic by default... another option is to have a default topic like `general`


Having hundreds of messages with no way to tell them apart is an absolute nightmare. Zulip doesn't require a subject for every message, but it does impose some discipline, and that's a good thing.


I knew Zulip already, and while reading the blog post I was thinking, Zulip needs a way to publish topics in a web format (web archive) I was surprised to see many comments about this in this HN discussion and getting to know it is already in Zulip roadmap.

I will definitely try to help develop such feature as it might be the killer feature for me to use it as a daily driver.


What I hate about all the team chats altogether is lack of threading (discussion trees). IMHO threaded discussion model like we do here on HN is by order of magnitude more constructive and I can see no benefit in real-time chatting as compared to the way it works here.


You haven't used team chat for work? Then, things tend to happen chronologically, like, step by step problem solving, or doing something together. In such situations, it can be more important to find the most recent comments, than to find any "best" comments.

It's about what matters most: Knowing what's happening right now, what everyone is doing, what one is supposed to do next. Then, chronological team chat. Versus finding the best comments, e.g. when discussing a news article, or pro and cons about an idea.

We were using Slack at my last job, and it was great (now I don't like Slack any longer though, not after they added their weird threading. I like Zulip instead). Slack & Zulip = good sometimes, HN = good for other things.


We had been using Slack at a job and that was plain horrible. Say something, it drowns quickly pushed away by newly arriving messages and nobody ever remembers the problem you've mentioned unless you repeat times and times again. I've quit the job because of this. If there was a tree everybody would see an outline of problems and comments that have not been answered would be hard to ignore. IMHO chats are handy for casual personal communication and absolutely unsuitable for a meaningful conversation involving more than 2 people.


Hmm I recognize that. I mean, important information / answers / questions, in a chat-only community, that scroll up, away and are gone.

Aha you have in mind a chronological "chat" / discussion, with threads? Rather than a best-comment-first HN discussion page?

If you use something else than Slack now, it'd be interesting to hear what that could be?


Are there any apps with better threads support than slack but still allow un-threaded messages within channels? I find zulip's model too restrictive for when you want to have simple real-time chat about a certain topic.


Is there a one-click installer for this yet? i.e. a pre-built image for Digital Ocean or similar.

I'm moderately curious but so far I've not gathered enough motivation to mess around with an install.


We actually are working on a one-click Digital Ocean installer right now!

See https://github.com/zulip/zulip/pull/11622 for the code; it should be in their marketplace in a few weeks.

That said, if you make just a Digital Ocean VM and run our install script, it'll Just Work and you'll get the same experience after like 10 minutes of non-interactive installation.


Good stuff. I seem to remember the installation around the time Zulip was first open-sourced was pretty fiddly. I'm glad you've made progress.


any way for an admin / moderator to see other user ip addys / hostnames?

Any way for moderators to ban a user and an ip subnet, or cidr or hostname associated?

Any way to unban / see list of bans and reasons?

Isit possible for someone to see the ip addys of others in the chat? (some systems change ip at the server level, some send info like p2p and each chat user can find all the other users ips in various ways )

Interested, but without serious modding tools can't test it for our use cases.


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


>Zulip is the world’s most productive team chat software

What does this mean?


It literally has 950 GitHub issues. How is that possible?


Lots of feature/change requests.


We are using https://github.com/Canop/miaou to stay productive, loads fast, markdown support, replies, channels




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: