Setting up a real-time chat service at

We should have a chat server, for all the reasons given in the “Choosing communications forums” discussion over at GitHub. At the Summit, there seemed to be consensus that it should be a FOSS tool. I also think having it hosted in the domain would be good (to match the Discourse instance). So how about:

If someone could point that hostname to, then I’ll finish configuration of the Zulip server :-).

(It would help to have the DNS in place because it’s hard to get certbot to complete the LetsEncrypt setup based on just /etc/hosts entries, ahem.)

Why Zulip?

  1. It can bridge with Matrix, for those who are comfortable using Matrix clients, but it also supports plain-old username/password accounts (whereas requires 3rd-party authentication from Google, GitHub, or Twitter, if you’re not coming in via Matrix).
  2. The UI pretty easy for non-technical people to use too. (One Zulip instance I hang out in has lots of non-tech people active, and they are pretty comfortable in it.)
  3. I’ve seen it adopted by other communities that have a combination of developers and users all taking part in chats, and it seems to work quite well – but it also works well for development-focused discussions.
  4. It supports Markdown formatting in messages.
  5. It has a plugin ecosystem.
  6. It has an active upstream.

If we have consensus on Zulip, then I’ll proceed (once that DNS is set up). If we don’t have consensus, let’s discuss here. Whatever we decide on, IMHO is the place it should live.

1 Like

@kfogel any chance you could share some screenshots from zulips that you are describing or maybe plan and host a time for a screenshare? I’m pretty hesitant on Zulip based on the experience I had on another project, but I recognize that in most cases these are issues of adoptions and norms, so I am open to being convinced.

Also — as most folks aren’t on discourse yet, we might need to communicate this discussion is happening here via another channel (email, etc) to get people engaged and weighing in!

1 Like

Hey, @georgiamoon. Sure! Want to just create an account over at right now and meet me there in the “#general” stream?

I don’t think it’s zero-effort to learn, of course (no tool is), and I’d like to learn more about your experience with that other project. We could have that discussion in Zulip, so that you’re testing it while we talk, for efficiency?

Btw, @georgiamoon, I also posted in about this discussion (as well as in the original GitHub discussion forum, and I saw you responded there that you would hop over here).

I’m going to head to bed now, but I’ll be in most of tomorrow if you want to do some Zulip test-driving / discussion there.

The chosen tool being open source where possible goes without saying - and to be clear there are plenty of open source options - so I don’t need to mention more!

My first question would be - what would Zulip be used to communicate? And by who?

Like @georgiamoon I’m reluctant for Zulip to be suggested also. On a previous project where I was one of the development team, I found it actually decreased my want/willingness to communicate. (Which must be a first for me)

The requirement for putting a message in a stream was just an unnecessary barrier for communication. The level of specificity of where to communicate was too high. It came to the point of having multiple streams discussing the same topic - but by different people. Where do I post this message?

I could imagine Zulip being more applicable to discussions which were focused around pre-determined subjects - like git issues, PRs etc - where all people involved in that subject discuss.

The platform being used by the tech implementors needs to be accessible for those who, are not involved in the day-to-day implementation related discussions. I’m not sure if Zulip would be it.

About the DNS, sure seems to make sense.

Hey, @bernard. I don’t think anyone’s proposing that presence in chat be necessary for anyone – it’s purely opportunistic: for those who want to chat in real time, it provides a convenient place to do that. It also provides a place for users / deployers who want to get a quick answer to a question to come and see who’s around.

In other words, it really is analogous to the role IRC often plays, just with a better user interface. In Hypha, the proposal here is just that Zulip take the role Gitter plays now (the issues with Gitter being that it’s not a great UI for many people, and requires 3rd-party authn unless you’re coming through Matrix, and many people – especially non-technical people – are not coming through Matrix).

The primary & official project forum would continue to be Discourse. “Official” in the sense that a decision can be made and referred to in Discourse, and everyone will have had a chance to participate because it’s asynhronous.

I hope it’s clear that I leaned toward Zulip precisely because (over at we do have the experience of non-technical people coming in and using it comfortably – in fact, we have had this experience repeatedly. I do hear you about the sometimes-annoying burden of choosing a topic, but in practice people seem to do fine; mostly they follow a given high-level stream, and are less fussy about the topic headings within that stream. There are times when separating into a separate topic can be useful, but I agree that it’s sometimes just an annoyance. ~shrug~ Nothing’s perfect.

Also, for the record:

I wouldn’t be horrified if we just stayed on, personally. I can go get a Matrix client and use that (instead of authenticating through Twitter, which is what I’m currently doing, and which makes me ashamed :slight_smile: ). But doesn’t live in the domain, and UI-wise it isn’t a great experience for people who are just dropping by for a quick chat and who aren’t making an investment in learning the chat tool.

I simply thought that we’d sort of consensed (or came close to agreeing?) that some kind of FOSS chat system that lives in the domain should replace, and I had volunteered to follow up on the discussion and install the instance if we agreed.

If we don’t have consensus, then we stay at by default I guess (?).

Because this discussion seems to be happening in two places, I’m putting a link here to my reply over in “Choosing communications forums” in GitHub Discussions.

In that reply, I suggest sticking with Gitter as status quo for a while, because we clearly don’t have consensus on Zulip.

Anything important that ones needs to find/reference/act on at a later date should be here on Discourse or in an GitHub issue is my firm belief.

Having too many places to look for information is stressful for me.

Gitter I find unsatisfactory. Threads e.g. show up in differently bad ways in the web and iOS app interfaces.

Zulip I have never used.

Could we simple use a Signal group for chats? I guess we all already use Signal in any case?

All for trying something (many things) other than Gitter via, so long that we do good by the shared understanding that information there is ephemeral/throw-away (so that we can bounce on to something else easily). is throwing a NET::ERR_CERT_COMMON_NAME_INVALID error for me in chrome.

glad to have a signal group but it doesn’t fill the need for me. i really appreciate the github integrations > log of stuff that happened recently. many times I go into gitter (or slack before) to ask someone a question only to see recent github activity there provide an answer for me.

let’s give zulip a test and keep the discussion here going to highlight the pros/cons people experience.

@danblah I didn’t finish setting up the Zulip because it wasn’t clear to me that we were going to use it (based on the discussion here). I’ll finish setting it up.

+1 on the understanding that chat is ephemeral and unofficial, and that the asynchronous is the one where the deep/permanent discussions happen.

Sorry for my delay in replying! It’s been a hectic week as I’ve been prepping for my parental leave. I’ll say that given I’ll be out for a bit and a more intermittent user generally, that I can defer to the majority opinion on this.

@kfogel I probably won’t have time to test for the next 2 months as I’ll be on leave, but definitely don’t wait for me to make a decision!

1 Like

@frjo, this is a duplicate of a message I sent in as well:

Hey, sorry to switch things on you like this, but could I trouble you re-point “” to instead? We decided to use a dedicated server for this.

@georgiamoon – gotcha. Have a wonderful parental leave, and we’ll see you when you’re back (whatever our comms forums are by then)!

@frjo Same as before: DNS A-pointer is all that’s needed right now. There might be some MX/SPF/DKIM/DMARC stuff to do later, but one step at time.

Meanwhile, it’s set up for now at . As soon as the DNS is updated, I’ll refresh the server to know its proper hostname (“”) and will configure its email then, as well as redo its cert. Again, my apologies for the DNS inconvenience: I had forgotten that Zulip, in its default production installation method, basically wants the whole server to itself.

No problem. Chat A-pointer is changed to

Mailgun is setup to send mail for if that can be used.

W00t! Thank you – that was fast. I’m both delighted and disappointed to see that I’m not the only one working on a Sunday :-).

Yes, Mailgun can be used; in fact, Zulip upstream recommends it. I assume that is the STMP host; all I need is a username and password to configure Zulip with. Want to send me those out of band? I’ll send you a GPG signed email with my key in a moment, and my Signal number. (Happy to do a live video key verification if you’d like.)

Signal should work well for out of band.

Can not Zulip use Mailgun API key?