Exploring new communication channels


Thank’s @seanmonstar for pointing out that outstanding feature request, which unfortunately doesn’t seem to be moving anywhere (since 2015)…

This is exactly why I also said that at the moment Discourse can’t actually be used as a replacement for a mailing list – although from all the other alternatives it comes closer.

@josh Please understand that this issue is not a peculiarity of GMail; this is just how mailing-list mechanics should work as established by years of “de-facto” standards. To summarize:

  • all emails sent through a mailing list should have the List-Id (and other headers set); (Discourse does this;)
  • the Reply-To header should be changed from the original authors address to the email address of the mailing list;
  • the To and Cc headers shouldn’t be changed by the mailing list; (thus only if the original author puts you in To or Cc, sort like an @ mention in Discourse, would your email address appear in those headers;) and unfortunately Discourse breaks this “rule”…

And as seen:

Nonetheless, if this is an issue for you, you could report it upstream to Discourse.

isn’t actually working, as the issue is known since 2014…

Moreover I don’t even think it’s fair to say “it’s not our problem, go complain to the developer of this third party solution we are using”… (They didn’t force us to use their system; we choose it, and thus we should take the responsibility for it.)

See bellow a few other people making similar points. Which again, although they mention GMail, that is mainly because GMail has a 25% market share (as per various studies) of the overall email clients, and I bet it’s closer to 75% (my guess) for “technical” people.


This is getting off-topic. Can I suggest that the discussion of mailing list software move to another thread?

Absolutely not. If I want to reply and include the list, I’ll hit reply-to-all. If I want to reply to the sender, privately, I’ll hit reply. Do not break reply-to. (This is a heavily debated topic, and I’ve seen arguments for both sides. At the very least, however, I would argue that no mailing list software should force the mangling of reply-to.)

I absolutely agree with this.


So more on-topic again… is it possible that Discord’s handling of mentions is really bad? This morning I got a notification that I was mentioned in the #design channel. So I clicked that channel, expecting some way to jump directly to the mention. I saw no mention. Then I scrolled through the backlog for 2 minutes until giving up, and eventually finding the mention using search. Then I realized it is not even highlighted – the @RalfJ is rendered exactly like e.g. @aturon! Not sure how I am supposed to even notice that then? (Btw, when you are in the middle of the backlog in Discord, you cannot even tell which day you are looking at – it just shows the time. Gitter has a tooltip on the time showing the day.)

So I’m sorry for anyone pinging me in any Discord channel, but this is pretty much unusable and I assume I will frequently miss @mentions. IRC clients will typically highlight messages where I am mentioned in bright orange or so, and Gitter does this really well (with a box in the top-right corner saying how many unread mentions there are, and a click bringing me to the next).

EDIT: I just saw that the message with the mention has a slightly different background color. I guess when you know about that that can be enough of a clue, but expecting some strong signal that’s visible even when scrolling at full speed, I totally did not see this at all.

(I hope this doesn’t come across the wrong way here. I figured this is the right place to list points of comparison between Gitter and Discord and others. I can stop any time :wink: )


You can scroll directly to the mention by clicking on the “@” button to see a list of mentions, either globally or filtered by server and channel. The button is in the upper-right corner on desktop, and at the bottom of the sidebar on mobile.

All messages show the full date, along with day separators, in “Cozy” appearance, if not “Compact.” That should be fixable though.


I don’t think Discord is the right choice for the Rust community. My reasons are purely political and philosophical as I think Discord itself has a lot of great features and I don’t have the accessibility issues that hinder me using it so I can’t speak about those.

  • Discord is too gaming focused — Discord is a gaming platform, nothing about “The Rust Programming Language” server says it’s a place that the Rust community has discussion on the language or programming. It sounds like the place the community comes to play games.

    Discord’s marketing as a gaming platform affects how our server looks. Now this might be a meaningless distinction for some but this matters when someone who is new is expected to get a gaming app to discuss programming.

    This also plays into the fact that discord is blacklisted in most corporate environments because it is marked as a “gaming app”. Discord’s nature as a gaming app is inherently exclusionary for some people who to come to participate in Rust.

  • Discord is closed source — Rust is a large programming community, over 40,000 people on Reddit and as difficult as IRC is to use we’re the largest community on the Mozilla servers, with both #rust and #rust-beginners containing over a 1,000 people. Whatever platform we settle is going to experience a large increase in traffic and interest.

    Putting that traffic into Discord just makes Discord’s traffic look better, no one who comes can help improve Discord for the Rust community, we’re beholden to Discord to handle our problems with their platform. That is completely unproductive. We should put our community in a place where we can build the tools we require without worrying about a third party’s approval, and we should be able to participate in the making platform better for all.

  • Discord is VC funded — There has been a quite a bit of discussion in this thread about Discord the company’s behaviour and response, any assurance by Discord from people in the company that they will be benevolent is an empty promise. Even if the promises were made by the CEO and were made in good faith, when the time comes they’re going to prioritise their investors over us.

    We can already see this in Twitter, which openly embraced all things people have mentioned they want from Discord such as bots and third party clients. Then when their investors have decided they want to see a return, they made it impossible to create new third party clients, they also set restrictions on the ones that existed before to try and stifle people using them. They introduce new features without API endpoints so that the people who continue to use those clients have a worse experience.

    Discord is incentivised to go down the same route as that is what is profitable for them. We should should be on a platform that is profitable for all.


Actually, that is not the case.

I was just mentioned in the clippy channel, leading to a read “1” in the favicon and next to the “Rust server”. However, going to the Rust server showed no indication of a mention, anywhere. So I thought I had already seen it, but switching to DMs made the “1” on the Rust server appear again. I hit F5 thinking there was stale state, and finally had the idea that I could un-hide muted channels, and there I saw the mention.

I also find that @mention-completion often picks the wrong user – some user is selected, I hit “tab”, some other user gets completed.

On my personal bug tally, I’ve hit more bugs with Discord now than I ever had with Gitter.


It may be so; but we were experiencing dropped messages and latency at a staggering rate and it was happening to most of us. So staying on Gitter just became untenable and I’m happy that we moved away.


Discord bugs seem to be far more of the “annoying UI behavior” variety than the “literally cannot use the thing” variety.

@RalfJung Ah, that’s unfortunate. I must have been referring to the behavior around collapsed groups rather than hidden muted channels? I know I’ve seen it do what you want in some scenario before.


Yet another data point :-).

I would rather not use Discord for this kind of thing.

To start, the Android client no longer works at all without Google Play Services (it used to, but then CAPTCHAs were added and the old versions no longer connect, and the new versions require Google Play Services).

The ban on third-party clients means that this issue cannot be worked around without upsetting Discord.

Personally I have ended up migrating from Discord to a self-hosted Matrix server, using a Discord bot bridge to communicate in Discord channels. The bot works very well, even showing the person’s Matrix name and avatar on Discord – with a ‘BOT’ flair but otherwise looking like a real person.

So if Discord is chosen as the choice for Rust, I hope there will at least be a bridge to Matrix or something along those lines.


An update on the screen reader situation:


Whatever Discord says, it doesn’t change the fact that they don’t allow third-party clients nor mods (their ToS don’t allow them, and that’s all that matters, private chatter with employees doesn’t count), and that definitely reduces the possibilities for disabled people and power users to tweak their usage of the service to their very own specific needs.


Yep, especially in today’s environment where you can be charged with “Misuse/Hacking of a Computer System” for violating the terms of service. It happens.


I said I’d chime in on this thread on Twitter a couple weeks ago. Better late than never. I believe I’ve read all the accessibility-related bits of this thread and i’m glad to see others raising and caring about that aspect.

The short version of the proprietary chat platforms and accessibility is that they aren’t accessible (or if they are, not productively so), and the short version of the “We’ll work on screen reader support” response is that 99% of the time they never do anything. The only reason I’m even mildly hopeful in this case is that it’s Mozilla asking, and so perhaps this time will be different.

But let’s assume that Discord goes ahead and does accessibility as top priority. They’re at least a year from being productive. It’s incredibly hard to take an app like this that wasn’t built with accessibility from day one and use Aria to “fix” the fact that you didn’t use HTMl right in the first place.

As a case and point, Slack. I’ve personally spoken with their accessibility team, have been using it for a year, and managed to accidentally and independently verify that the person leading their accessibility team is highly qualified. I’m really pessimistic when it comes to believing people are trying, but I have no way to spin Slack’s progress into that sort of narrative. A year ago it was hellish. Now it’s not hellish, but is still missing things and has bugs that make productivity lower than it should be. Some of the latest stuff (accessible search for instance) has come with an entirely new dialog for everyone, and my personal suspicion is that this was in part because it’s often literally easier to throw out the UI code and rewrite an accessible version than it is to retrofit.

Slack started off accessible enough that a 50 line or so Greasemonkey was able to get it far enough for me to use it with my job a year ago, before the improvements on their end achieved momentum. It was still horribly inefficient and buggy, but at least usable. Discord is starting in an even worse place than Slack.

Put simply, you need to be able to read messages fast enough to keep up with the chat while still being able to quickly reply simultaneously, generally navigate the app very quickly, and there’s a lot of big and little stuff that’s not obvious that has to go into it to achieve that goal. Slack was at least in a position where I could have made a list of what needed to happen a year ago, whereas Discord isn’t even far enough for me to get as far as reading messages at all last time I tried it. I haven’t tried it since whatever changes they rolled out recently, but the point I’m trying to make here is that even assuming goodwill and massive resources, it’s not going to be quick to fix.

I wish I could give a good alternative, but the only 3 platforms I’m aware of that are fully accessible to a degree wherein you can be productive are e-mail, XMPP, and IRC. Slack is ok. Everything else varies from can’t read the messages to could be fixed with some work. if Rust moves to a proprietary platform and cares about accessibility, I expect that pressure will have to be applied (and as I said above: it’s Mozilla, for once it’s a big enough org that that might work). we (blind people) aren’t powerful enough to get anything but empty promises on our own.

I also wish I could say that this is sufficient argument to stay on IRC or use mail, but the disappointing truth is that I do have to acknowledge that IRC is exclusionary for a lot of people. Being in the excluded group sucks, but nonetheless the excluded group here is a lot smaller than the group that would be included with the move to Discord and/or whichever other platform. I’d prefer something open source if only because there’s more of an opportunity there to fix accessibility and keep it fixed.

I’ll try to keep on top of this thread in order to answer questions, but my life is incredibly chaotic for the time being.


As far as I’m concerned, the optimal solution seems to be moving to a chat platform that has backwards-compatibility with existing IRC users whilst also making things significantly easier for new non-IRC users.

Gitter fulfilled these criteria rather well; I can connect to it with my IRC client, but regular users have a glossy web client to use instead. Discord is okay here; I can connect to it with bitlbee-discord, which works pretty well but is, as previously discussed, not something sanctioned by Discord staff. The question is: if Discord were to suddenly start cracking down on custom client users, as their ToS allows them to do, would the Rust team migrate away? If the answer is yes, I have no qualms with Discord.

Perhaps a better solution would be to set up something like discord-irc between the moznet IRC channels and the Discord ones, which both reduces setup time/faff for IRC users and moves us onto an officially-sanctioned way of using Discord.

I think @aturon is pretty correct with this analysis - if all the discussion for Rust ends up being on Discord, most people will just use Discord. However, there are still some problems with this arrangement: blind users et al. are excluded, due to accessibility issues, and, perhaps more pressingly, the degree to which users idle on Discord would probably be reduced. IRC clients use very little CPU and RAM compared to the bloated Discord web client; therefore, some people will be unwilling to run Discord in the background all the time for notifications, while IRC remains usable for them. Essentially, Discord seems to sacrifice accessibility for some users (blind, having low-power computers, etc) whilst giving it to another set of users (new community members who aren’t used to IRC et al.).


Hi, Zulip developer here. At the risk of cross-posting with Where should the compiler team (and perhaps working groups) chat?, I just wanted to offer support, and answer any questions you may have about Zulip.

To answer some of the questions from this thread:

  • Business model: We sell hosting on zulipchat.com, and enterprise support for on-premise deployments: https://zulipchat.com/plans/.

  • Deleting of threads: Admins can delete messages and ban users, and also rename threads. Zulip threads are meant to be ephemeral, with the moderation (by design) happening on streams, messages, and users.

  • Vendor lock-in: Zulip runs both in the cloud and on-premise, and we provide full exports: https://zulipchat.com/help/export-your-organization. The on-premise product is the same as the SAAS product, and there is no proprietary code (so e.g. running Zulip locally doesn’t need a a license.)

  • Mobile: We’re working on it. We’ve put a lot of work on it since the beginning of the summer, and are going to continue to do so. The current version (released today) is already a lot more reliable than the version in July, and I use it pretty heavily when travelling.

  • Bridging: It’s hard to satisfactorily bridge Zulip with IRC or Discord, due to the different conversation models, but we do bridge with email.

For accessibility: I suspect we’re considerably farther along than Discord is, and our goal is to make the main webapp a great experience for blind users. We’re not there yet, but I think we’ve gotten the basic framework right, and getting to good accessibility won’t involve throwing out lots of html.

Some things we have made a lot of progress on in the accessibility space are:

  • Nearly everything in Zulip can be navigated via the keyboard (many of the developers of Zulip exclusively navigate Zulip from the keyboard, at this point).

  • We have a terminal client (in alpha, but all of the basic functionality is there, and we’d love feedback).

  • We bridge with email. It doesn’t support things like emoji reactions, but the basic “read and reply” functionality is there.

I’ll be checking this thread for a bit, but also feel free to find me on https://chat.zulip.org (Zulip community server) or at support@zulipchat.com at any time.


Something that occurred to me after watching RustConf’s opening keynote, where it talks about the openness between the teams and the community. Is that Discord’s conversations aren’t able to be publicly linked. The team meetings should not be hidden behind a signup page, we should be able to link team conversations on the GitHub or Discourse with no wall to view them.


Not every team has open meetings today.


I didn’t say that they did, but we would be going from some(mostly?) open meetings to none. That is a step backward in being more open. I’m not saying all communication should be, for example moderation team shouldn’t have open meetings. But unless there is a good reason for it not to be we should have those meetings open and easily linkable.


I would hope that we could work with Discord on making links to logs public for discords like ours where there’s no need to sign up (i.e., intentionally open), but even if that’s not possible, I think we can put together a bot that posts public logs…


Just as a note, Discord is better than IRC in terms of logs, since Discord has a history to its messages (even if it is behind joining the server) whereas IRC has no intrinsic history.

If a history bot is appropriate for IRC in this regard, this isn’t a point against Discord in comparison to IRC. The bot is probably just as simple to get working as well, assuming you choose a language with bindings to the API.

A Discord log bot does have to handle edits in some manner though.