ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

An instantaneous chat platform for the ROS community

Some of us around here like our RAM, though. Just sayin.

1 Like

I have 16GB of ram on my laptop, I can dedicate 25% of it for my messaging client … that is reasonable, right?


1 Like

how to join

Hi, I’d also recommend Slack. Great for team communication, free, very good on all platforms.

We explicitly stopped using slack:


After feedback about the failings of Google Groups and the non-open,
proprietary nature of Slack, we launched an experiment migrating the ROS
Java SIG from a Google Groups mailing list to Discourse.

Slack is officially deprecated: you are free to continue using it, but if
you want something to come onto the radar of the ROS team, you should
prefer to use Discourse, IRC, Github, or email.

So in some since this topic is a rehash of discussions we had then, but notably at that time we didn’t really consider discord or rocketchat (AFAIR).

One big issue was the ability to get access to historical chat records publicly via a website or some rest API, and the fact that Slack limits chat backlogs if you don’t pay for it (not sure if that’s still the case).

It’s a valid concern about the other options like discord (it has chat logs available via a rest API, but no convenient export feature) and rocketchat (presumably not an issue since it can be self-hosted).

1 Like

That was one of the issues I had with slack. The monetization of the free tier subscription really limited the history capabilities, making it unreliable to link back to reference a previous discussion given it could disappear with the rolling-window archives. Unless that is one where to pay out for a subscription plan, which was per user last time I checked, making it hard to apply to open communities.

That’s a real good one! One hesitation I had with most of the mentioned solution thus far was that the channel for the instant messaging was rather wholistickly bound to the client/host-provider. The nice thing about email and IRC (and now matrix) is that it the protocol is decoupled from the client provider.

Here is a feature breakout of the available clients they list (voip being one of them):

One of the things about instantaneous chat is that you shouldn’t need to do that too often, especially if we have multiple channels set up for major segments of ROS development. So it’s not a killer need for me. I do agree that it is a very nice convenience, though.

Discord does support pre-formatted text (its messages are all Markdown), but as you say it doesn’t go beyond that to things like syntax highlighting like Slack does.

The backlogs are still locked up and it’s still per user and still really really expensive. It’s 850 yen per user per month (sorry, the website absolutely refuses to give me prices in $US), and twice that if you want features like exporting, not just keeping, your backlogs.

Actually the sheer cost of using Slack is probably the biggest thing against it, in my opinion. It’s not really suitable for an open source community. Imagine if we wanted all the people signed up for this Discourse to be able to use it with full privileges: the cost would be over $400,000 per year by my rough calculation. Slack does allow for “external guests” at the paid tiers, but they need to be individually invited to each channel they are needed in. If they are given access to multiple channels, then you get billed as per a paid user for each guest. If they are given access to just a single channel, only then are they free, but you can only have 5 per paid user, so we would still need to pay a huge sum to get everyone into Slack.

I agree with @ruffsl. That one does look really nice. Tellingly, the iOS client is frequently updated and doesn’t look like crap. The exception is support for VoIP: While the protocol provides support, only the web, Android and iOS clients provide it.

In regards to Matrix, checkout the talk by the core dev team from FOSDEM 2019. It was posted earlier this month and covers a bit of the dilemma we’ve been sharing here wrt to ecosystem silos:

Specific times of note:

5:08 Decentralised network and Optional bridging


43:45 Latest Riot Client


As of writing, it doesn’t look like main riot site has updated the client to reflect to one demoed, but you can still test that latest build locally, or by going visiting experimental page, as posted here.

The desktop clients are ridiculously heavy weight indeed, since most of these chat clients are built on top of Electron. However most of them also provide a web interface that can just be loaded in a browser, which reduces the memory usage to more acceptable levels. I’ve set up Whatsapp, Discord and Slack like this as pinned tabs in Firefox and according to the task manager of Firefox they now use 35, 75 and 110 MB of RAM respectively.

In the current environment where I’m involved, it’s used for team collaboration among a team that works together on 2 projects with a common base. Multiple channels have been created for subtopics within the projects and the common base, so that discussion per channel can be focused on 1 topic. Still it happens frequently that discussions end up quite chaotic and people end up using 1-on-1 chat (which is not public) to discuss more final details. Of course this also depends on the users, but just want to bring this into the discussion.

On another note: before using Slack and Discord we’ve been using Mattermost and personally I liked it better than both Discord and Slack. It’s very similar to Slack in user experience, has native clients for Windows/Linux/Mac/Android/iOS, supports audio/video, sharing code snippets etc. and is open source. It can be self-hosted, but they can also do the hosting and have specific pricing for open source projects.

The more I look at Matrix, the more I like it.

If VoIP is in the reference implementations now and will reach the other clients as they update, then maybe Matrix combined with using something like in the meantime is a good solution?

Has there been any movement on this topic? Was it discussed at the recent TSC meeting?

I have been thinking about setting up a matrix server if nobody else does it by next week.

After one of the more popular matrix client’s available, , announced there first 1.0 release, I went ahead and connected OSRF directly to reserve and hold down a namespace on the largest free matrix hosting server. See Riot’s 1.0 announcement here:

We conducted a dry run, creating a matrix community for rosorg to host multiple rooms (like channels) under a cohesive community (like an organization). More info on matrix communities here:

We tested @user mentions, direct messing, archive visibility, VoIP, and integration with the Riot’s web and desktop clients. It all seemed to work quite well; p2p latency was small, and video/audio resolution/frame rate where smooth), including screen sharing and group in-call management. Overall, I was quite pleased.
:star: :star: :star: :star: :star:

Others still had some reservations in that the administration and user moderation setting where not as feature compete as those in Discord’s product, e.g. hearchal delegations of sub-admin privileges. I can’t compare given I’ve not yet used the either admin panels, yet I’m not so sure this would be much of a road block given the level of developer activity and user adoption rates, these features could be integrated:

Last we met, it seemed OSRF was still inclined towards falling back on the old ICR channel on freenode. Given the level of community engagement and user adoption is had over the years, I don’t think IRC would be likely to change its spots soon. Some of the pros/cons for IRC off the top of my head:

  • pros:
    • Open Standard & Protocol
      • Unlike Discord, users can choose from a number of available and possible open source clients to join a network. Discord seem to include some ToS that terminates user accounts of those caught using non-native discord clients software.
    • Low barrier to entry
      • Users don’t have to sign up for a potential subscription model free/paid plan options to follow the community, while user authentication is still possible for trusted participation.
  • cons:
    • Few user friendly features
      • IRC was designed for a previous era, where current web tech/crypto was still relatively in its infancy. Sure there are lots TUI integrations and clients, but they make little use of modern designs and UX.
    • Limited visibility
      • Users must be perpetually logged into a channel to receive @pings or ealy catch up on previous discussions. Chasing IRC logs from (currently down) is a subpar workaround for usability, and inhibits spontaneously jumping into ongoing discussions just after joining.

To me, matrix seems to solve a lot of those cons while retaining many of the pros, and reminds me much of in the way old email lists have evolved into active discussion forums; in much the same way we’ve grown from mailman to discourse: -->

It seem like we could just as well evolve from IRC to Matrix, while also not breaking backward compatibility (for those who are still active there), like we did with integrating the discourse topics to mirror back to mailman threads. If desired, we could just as well bridge matrix with IRC (or Discord and whatever else if warranted) via matrix’s bridging integrations:

We did discuss this topic in our most recent ROS 2 TSC meeting. The forthcoming minutes from that meeting have more details, but I would summarize the consensus as a combination of the following:

  • What we do now isn’t perfect but seems to work OK. Perhaps we should focus on being more explicit early and often in communicating about designs for new features. We can do this using existing tools.
  • Let’s not introduce a new chat tool as an official comms channel because nobody needs yet another thing to check.
  • However, there’s value in migrating certain technical / design discussions to a chat system on demand. For that purpose, it’s not clear which is the best choice; for all its failings IRC still gets the job done in many situations.
  • There could be value in doing a regular call, perhaps called “office hours”, in which the core dev team communicates to whomever’s listening about what’s currently going on in the project, and then takes questions from folks. It would not be a forum for collecting TODOs for the core dev team. The Cartographer Open House was offered as a model to follow.

It doesn’t sound like we’ll setup any service, but honestly I think groups in (matrix) are very frustrating because (AFAICT) you cannot share permissions between channels. In general it’s just not as nice to use as a discord server if you have more than one or two channels, which means you’re more likely to put all conversations in one or a few channels which isn’t ideal. In discord can have many channels in a server and if you grant someone permissions in the server, then it can apply to any number of the channels. In matrix, again AFAIK, you need to add permissions to each channel separately for a user.

Matrix is definitely better than IRC, but in my opinion it’s still inferior to discord, not due to the quality of, or number of features in, the client, but from a conceptual standpoint. I understand why matrix did their design that way, and it may be the best open standard option out there, but there are a lot of benefits to the way discord organizes its concepts.

Again, kind of a moot point as there doesn’t seem to be interest in changing anything in this space officially.

Freenode runs a bridge. I just tried it out with another channel I manage on Freenode, and it works flawlessly. From a ( account, join this room and the bridge will just do its thing:

They call them “communities” for anyone doing a search.

Communities appear to be a relatively new feature. They do the job, but they kinda suck from a management perspective and from a UI perspective. It’s hard to find the place to add rooms to a community in the UI, rooms are added to communities rather than communities containing rooms, etc. They’ve made the room the top-level entity rather than the community and this has had significant flow-on effects for the management of things.

Looks like riot already has plans for addressing this:

I’m not entirely sure. One of the linked blogs still talks about communities having a mix of community rooms and global rooms, which implies they are not going to change the hierarchy, and in turn that we will not necessarily get easy-to-manage permissions for a bunch of rooms.

That’s exactly the difference I was talking about, you just put it much better than me :slight_smile: