I am considering an additional article to my Slackware Cloud Server series.

As I showed in that series, a Nextcloud server can be equipped with capable text, voice and video communication apps but they are self-contained. The Jitsi Meet stack contains an internal XMPP communication server and Nextcloud collabration apps can only connect to user accounts on other Nextcloud server instances (through a process called federation).
What if you wanted to collaborate with people on other networks, say, other clouds? In the past I would be quick to point to XMPP server solutions like Jabber but those seem to be disappearing. Two popular platforms exist which use completely different protocols: Matrix.org is built on top of its own Matrix open standard and Rocket.chat. is built with the Meteor JavaScript platform. These two also use federation to connect to other instances of their own product but on top of that, these servers offer bridges to a whole lot of other communication platforms, such as Teams, WhatsApp, IRC, Slack etc.

How well do these two integrate with Nextcloud? On my own cloud server (based on the Nextcloud platform) I installed Element for Nextcloud, which is an app to use the Matrix.org web client called Element (formerly riot.chat). Element can connect to existing Matrix.org servers out there, or you can setup a Matrix server yourself.
And then there is an alpha-quality app to integrate Rocket.chat into Nextcloud but it is not advised to install that on anything else than a testing environment.
Worth mentioning: both Matrix.org and Rocket.chat offer seamless integration of the Jitsi collaboration platform which is also covered in great detail in my article series.

I am happy with the Element app on Nextcloud, it allows me to talk to people in the Slackware Matrix room but also to connect to the Libera.Chat IRC network through a Matrix bridge. I did not try setting up my own Matrix.org homeserver yet. I was wondering whether I should do that eventually because as you can see in the Element configuration dialog on Nextcloud, you can make Element use your own private Jitsi service as well.
That would be an interesting extension of the capabilities of our own private Slackware Cloud Server!

But then I read the article about Nextcloud and Rocket.chat intensifying their collaboration to provide a deeper level of integration. This would for instance mean that during your Rocket.Chat conversations you will be able to access the data you store on your Nextcloud account. That would definitely bring a lot of added value to our Slackware Cloud server!

But since Rocket.chat is a commercial offering using an Open Source service, I also have been investigating whether there are differences between the ‘community’ open source version of Rocket.chat and the commercial subscriptions. There are of course features like redundancy, advanced monitoring and such that you need to pay for, but lacking that on a self-hosted service is not so relevant.

I found a few controversies that I think may be relevant for self-hosted Rocket.chat instances.

One is the fact that role and group mapping to and group sync with identity services (like our Keycloak server) are removed from the community server version as of 4.0 and became closed-source. See this article by fairchat for more detail.

The other is the artificial limit on push notifications. There’s some unproductive interactions between open source users/admins and the Rocket.chat support team (1, 2, ) about the requirement to register your self-hosted instance in order to use push notifications and about the subjectively low limit to the amount of notifications per day. Actually there is a good reason for limiting these notifications – Rocket.chat has millions of users and the company runs a global infrastructure to allow users to communicate with other platforms – the push gateway is what all the Rocket.chat clients connect to.
Community users don’t have to pay for using the gateway but are rate-limited as a consequence of that. It still sucks if you miss most of your notifications about new messages.

It is not trivial to setup your own push gateway: for mobile users (Apple and Google platforms) you’ll have to recompile the client and in the worst case you’ll have to pay Apple and Google for adding your custom client to their App Store. Seems like a bad architecture design to me. There is however at least one solution that may work, which you can host yourself and which does not need a custom-built mobile Rocket.chat client app: this Rocket.chat push gateway.

So dear readers… with all that background information on the table, what are your views with regard to Matrix.org and Rocket.chat? Do you prefer one over the other? Is there a reason to avoid one or the other? Do you have a need for an article here that describes the setup of one or the other?

Let me know – below in the comments section. Don’t hold back. I want to be informed with as much detail as you can give. Really wondering whether this will be a “vi versus emacs” type of discussion.
Eric