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
XMPP is in perfect condition, much better than before. Big corporations use it when they don’t want to rely on other big corporations. Ejabberd, Conversations for android. Video calls work perfectly and easy to set up.
I have matrix running on my vps, for me and some friends, it’s not integrated with my nextcloud instance, but have integrations with slack and telegram
anyway it’s running great (synapse), but I want to test dendrite as server as well
also did a lighting talk about matrix and federation at my work, we will use some ideas on a future project
didn’t like the business model of rocket.chat, so this was the main reason I’ve chosed matrix here
I double the XMPP request.
Prosody+Coturn+Dino+Conversations work quite well for me. Much better than a slow and buggy Matrix.
Thanks guys for sharing your opinions. It’s really nice to see people chime in who actually use or deploy these technologies.
I think that this discussion on HackerNews is worth reading, it sums up my own doubts about the usefulness of XMPP in a collaborative environment: https://news.ycombinator.com/item?id=17064616
Basically, everyone can write their own extensions to XMPP and create a server, or a client, implementing those features. But you need servers and clients, and all users using clients with the same XMPP extensions/features, to make it really useful.
I have been using Jabber extensively in the past, and it was me who added mcabber package to Slackware. It is easy to use, and it is relatively easy to setup a server.
But I need some real convincing that a second XMPP server adds value to my Cloud Server concept, seeing that Prosody is already included.
To re-iterate: I am looking for the best solution to bridge the communication gap with other networks.
If you have implemented all the stuff I documented in my article series and you have no need for this kind of bridging, then you also would not be helped with Matrix or Rocket.chat I think. Or perhaps I missed recent developments in XMPP-powered software solutions. Would be interested in seeing me proved wrong 🙂
I self host a matrix server and a variety of different bridges for a couple of years. It allows me to just use matrix as my primary communication medium with all my contacts. I have noticed that the matrix team has been evolving their specs and element at rapid pace with new features coming very often. Matrix also allows you to use your own push notification service which uses gotify and unified push, just like the self hostable rocket.chat push gateway, if you want to fully de-google/apple your setup.
I do not really have much to say about rocket.chat or XMPP as I have not used it to the same degree unless over a bridge.
Thanks for everything Eric!
> 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!
Sure thing. This is a great value addition to self-hosted service. But at what price?
To force artificial rating limits, non-free networks services (as the gateway is in practice) and other complex issues (like compiling a client or paying so it may become available) on users willing to self-host a chat solution is such an expensive price tag.
On top of that, if a service was greed enough to implement the above, rest assured it’s ready to impose other limitations as soon as their ‘free’ user base grows. We all have seen that happens many times before… this chat solution will not be the first nor the last. Their business model is clear and there’s no reason to believe it will concede to non-paying people.
So, despite having integrated access to your assets is a great feature indeed, I go for Matrix in a blink of an eye. There you can bridge to other networks (the primary goal of your proposal as I understand) and have the features to share your resources within at least some of that bridges, even tho it’s not that well integrated with the self-hosted cloud storage.
Hi,
I am really interested in Matrix.
My main point is to bridge to other networks (Google, Facebook, Microsoft, et al.) and to have single interface for messaging.
Including SMS on mobile phone, which Matrix is apparently capable of doing.
Thank you for the series! 🙂
—
Best regards,
Andrzej Telszewski
I don’t have a horse in any of those races but FWIW between Matrix and Rocket I’d go for Matrix hands down.
Rocket’s self-hosted setup seems overly complicated, and I also agree with Deny Dias’ opinion about it.
Cheers!
Caveat: I most probably won’t have the need and almost certainly not the time to set up a NextCloud server any time soon (read: in this life time), so take this with a pinch of salt. I am only using Matrix through Element to stay in #slint @irc.libera.chat and in a family Telegram channel when my laptop is not connected to the Internet, and that suffices for my needs.
Now back to work, still about 300 packages to (re)build on top of Slackware 15.0 …
Cheers,
Didier
I recommend you to keep an eye on the XSF NewsLetter … XMPP is an Open Standard and a modern protocol, that keeps growing every day … look at the correct place.
https://xmpp.org/newsletter/
https://xmpp.org/categories/newsletter/