Mozilla IRC Sunset and the Rust channel

Welp. I hate the proliferation of N different walled-garden chat services with no good way to access them all from one place. Shutting down IRC doesn’t make things worse, exactly; the proliferation has already occurred and, in Rust’s case, the most important conversations left IRC quite some time ago. But it does remove the one outlet accessible from the greatest variety of clients, so it still feels like a step backwards.

I’m not in love with IRC. For all its old-school charm, it’s sorely missing basic features like persistence, chat history, and multi-client sync. Indeed, that’s long been the case, but the semi-recent explosion of new chat services (Slack is 5 years old, Discord is 3) made it more obvious, and users voted with their feet. I used to hope the IRCv3 project would fix things, but whether due to conservatism or lack of interest, they haven’t proposed the kind of big changes that would be needed to implement those features. As for me, even as someone willing to set up an IRC bouncer to provide those features for myself (I’ve also tried more specialized proxies like a Quassel server or Weechat relay), I’ve never actually been able to find a setup that works the way I want and supports the platforms I use.

But the result is that right now, I just don’t use any chat service regularly, even though that means I’m missing out on interesting Rust-related discussion, among other things.

I don’t have much hope that whatever replacement Mozilla settles on will improve the situation. Discord actually disallows third party clients in their ToS, though its competitors generally don’t. Matrix arguably shows the most promise in terms of openness, but the protocol is questionable, the server is slow, and the client is Electron. Most of the new chat services use Electron for their “desktop” clients, and I refuse to use Electron apps on my computer; even if I weren’t as stubborn as that, there’s still the fragmentation issue. As for alternative clients… there’s Volt, but it’s semi-vaporware and doesn’t support enough services and isn’t on mobile. There are various X-to-IRC bridges, but they don’t work too well, and there are no good IRC clients for iOS.

For now, I guess I’ll keep hoping that someone somewhere is working on the chat client of the future. Preferably written in Rust… :slight_smile:

9 Likes

I feel similar way. However, the dead horse I’m trying to ride is not IRC, but XMPP/Jabber. That one actually has some reasonable clients on both desktop and mobile. The protocol supports quite a few never features (thought not all are implemented on all the clients) ‒ multiline messages, formatting, downloadable server-side history, though probably not all of the „fancy“ ones.

I have a gitter←→IRC←→XMPP setup right now. It’s a pain and I would like to have it directly ‒ going through IRC for example splits multiline messages into bunch of single-line ones.

But I wonder if we could find enough unhappy people to be able to join forces, pick some existing protocol and bring it up to competitive state.

I feel a lot like you in these matters, and understand the concerns about proprietary walled gardens but let’s try to be pragmatic here and use our time and effort in the most productive way by focusing on the conversations to be had rather than the medium.

Ideally, pick one chat service, and one forum (this one?). They serve different purposes. The chat is a means of direct communication, useful for quickly moving the conversation forward. A video conference is similar but allows for a more natural conversation, so it also has its place. The forum is a place for more elaborate responses and more useful for conversations spanning days to weeks.

My concern is not that much about proprietary. It’s about usability. The problems I see are:

  • UX. Most of the chat services consider desktop as second-class citizen, offering a web app to interact with them. They can’t be customized to my liking, integrated in the rest of my system, etc. Sometimes, they offer a desktop client which is a webbrowser without the address bar going to their web app.
  • Fragmentation. Even if Rust chose just one chat service, Rust is not the whole world. I don’t like to have several tabs open, switching between them when switching the services.

By using the bridges into some common protocol, be it IRC, XMPP or Matrix, I can route all that into one program of my choice, eliminating most of the pains.

I certainly don’t want to drain the manpower working on the compiler or the language to do a chat platform. But if it happened that one project could solve the chat platform problem, try out some of the newer async things that are being developed and offer a learning ground to some beginners, or something, it wouldn’t have to be that bad a choice. But I guess discussion about such project would better go to users.rust-lang.org?

5 Likes

The thing I do which makes switching between Discord and Zulip tractable is that I have a pinned tab for each next to each other in Firefox.

That still means learning two UIs, having two sources of notifications, and other forms of overhead that make the situation less than ideal.

1 Like

Yeah, I’m not excited about having 2 different chat platforms, but it is a practical solution I found in the interim since we don’t seem to be coalescing around one of the chat platforms. Consider it a “pragmatic hack”. :wink:

1 Like

+1, and I’m glad that we got rid of the third one at least.

It would also be nice to get rid of the zoo of undiscoverable google-docs, dropbox-papers, hackmds, evernotes, github repos that are currently used for concurrent editing.

6 Likes

In terms of openness and usability, my ideal preference would be a self-hosted Mattermost server. It has a web interface, apps for Android and iOS, a desktop app, and open protocols that have allowed people to develop things like a text-based client and various bots. And all of that is open source.

We’d definitely need to hear from folks in the community who need accessibility features about whether there are clients that allow them to use Mattermost conveniently. And Mattermost doesn’t provide the same style of threading that Zulip does. Other than those two things, though, this feels like a workable solution with all the features I’ve seen people ask for.

4 Likes

Moving to discord is definitely a change for the worse for me. Barring the fact that discord is known for their extensive data collection, the worst issue is usability.

Precisely, it looks like I have no way of accessing the Rust channels from my smartphone.

  1. using Fennec F-Droid, nothing happens when I click “Accept invite”
  2. using LineageOS stock browser, I get a random duckduckgo.com redirect
  3. using the WebApps sandbox, I get a redirect to the Play Store website

If I manually enter the channel list, I get an unusable desktop interface. I don’t want to install the proprietary Discord Android app (the desktop one was notorious for scanning the process list, so I don’t trust the mobile), and I don’t have Google Play Services on my phone, so I wouldn’t get any notifications either.

In the times of IRC I would just install a client of my choice or use an XMPP-IRC bridge such as biboumi, which worked like charm.

Btw. you could’ve just go for self-hosted Rocket.Chat. (it’s not ideal, but certainly better than discord). That’s what my company is using all along.

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.