Tag: rocketchat

Posted on
by

I was surprised to receive a 2am automated message from ‘rocket.cat’ in our company’s self-hosted Rocket.chat instance. It was a notice from Rocket.chat alerting me that from now on registration is mandatory to use the Rocket.chat gateway to enable push notifications to mobile devices.

The reason we run our own instance is to be in full control of the data we share between ourselves in rocket.chat.
However, something that wasn’t clear to me before, push notifications in Rocket.chat involve multiple third parties without users giving explicit consent (which is very problematic in terms of GDPR). Especially as there is no way in Rocket.chat to finetune when/how you want to receive alerts, nor any meaningful instance wide settings, and the default is alerts get pushed always.

When you @user someone, or @all a channel, or even share any message in any channel, the server pushes an alert by default to the mobile devices of the users involved.
That push notification isn’t generated within your own server, or within the mobile applications after receiving the messages concerned directly from our server. It is generated by sending an alert to the Rocket.chat gateway. Through that gateway all alerts from every rocket.chat instance anywhere, self-hosted or not, pass. The connection is encrypted, but the content isn’t. The gateway then sends the alert onwards to Google and Apple, for them to generate the alert on the mobile devices involved when the mobile app isn’t running or in the background. Using Apple’s Push Notification Service and Google’s Firebase Cloud Messaging is common, I realise, but both allow encrypted and/or empty payloads, which doesn’t seem to happen here.
Rocket.chat put in the gateway as a workaround, where every alert gets send with their keys, to prevent independent instance owners needing to have their own keys to APNS and FCM (and as Rocket.chat suggests to compile their own mobile apps and have them accepted in the app store). I’m not knowledgeable enough about how push notifications generally work on mobile devices, but it surprised me that push notifications always require third party involvement this way.

Rocket.chat is now starting to enforce registration of instances to be able to use the gateway, because that gateway is becoming a major cost to them. Not surprisingly if all alerts of every single Rocket.chat user in the world pass through it. Because those costs are rising, they want to start charging for sending alerts above a certain threshold. To start charging they need you to register with them to both show you your usage and store your payment method.

I don’t like the existence of such a centralised bottle-neck. It also comes across as a next step of building on something that seems to have been implemented as a workaround fix to begin with.
This way, even if you run your own independent instance you’re still tethered to Rocket.chat the company indefinitely. It’s completely at odds with why we (and others I presume) run our own instance in the first place.

I therefore disabled all push notifications in our rocket.chat server.

Posted on
by

With my company we now have fully moved out of Slack and into Rocket.Chat. We’re hosting our own Rocket.Chat instance on a server in an Amsterdam data center.

We had been using Slack since 2016, and used it both for ourselves, and with some network partners we work with. Inviting in (government) clients we never did, because we couldn’t guarantee the location of the data shared. At some point we passed the free tier’s limits, meaning we’d have to upgrade to a paid plan to have access to our full history of messages.

Rocket.chat is an open source alternative that is offered as a service, but also can be self-hosted. We opted for a Rocket.chat specific package with OwnCube. It’s an Austrian company, but our Rocket.chat instance is hosted in the Netherlands.

Slack offers a very well working export function for all your data. Rocket.chat can easily import Slack archives, including user accounts, channels and everything else.

With the move complete, we now have full control over our own data and access to our entire history. The cost of hosting (11.50 / month) is less than Slack would already charge for 2 users when paid annually (12.50 / month). The difference being we have 14 users. That works out as over 85% costs saving. Adding users, such as clients during a project, doesn’t mean higher costs now either, while it will always be a better deal than Slack as long as there’s more than 1 person in the company.

We did keep the name ‘slack’ as the subdomain on which our self-hosted instance resides, to ease the transition somewhat. All of us switched to the Rocket.chat desktop and mobile apps (Elmine from Storymines helping with navigating the installs and activating the accounts for those who wanted some assistance).

Visually, and in terms of user experience human experience, it’s much the same as Slack. The only exception being the creation of bots, which requires some server side wrangling I haven’t looked into yet.

The move to Rocket.chat is part of a path to more company-wide information hygiene (e.g. we now make sure all of us use decent password managers with the data hosted on EU servers, and the next step is running our own cloud e.g. for collaborative editing with clients and partners), and more information security.

In reply to a post by Frank Meeuwsen

Well, yes, some of that social ‘cost of leaving’ plays a role. Yet:

It’s part of my company’s journey to better information security and data protection. Leaving silo’s, and Slack is just as much one as is Facebook, although with a different business model, is part of that. Similarly we’re starting to use our own cloud, in order to not use Google docs, Onedrive and the like. Our clients have different (and contradictory) rules against some of those silos, and we want to offer our own environment in which we can collaborate with clients as well. So our cloud and our Slack replacement run on our own server in a Dutch data center. This makes it easier to show GDPR compliance as well.

Within the company I’m the only heavy Slack user, taking part in about half a dozen Slack spaces. Still 90% of my Slack interaction is within my company.

Importing our Slack history into Rocket.chat, as well as that the URL of our Rocket.chat space is called Slack, help make a soft landing. Similarly Rocket.chat’s interface is similar to Slack’s.

Our cloud integrates well with Rocket, better than with Slack.

For mobile having another app on it is hardly an issue, given we all have half a dozen chat apps on it already.
For desktop it will be less automatic to make the switch, but adding Rocketchat to the dock will help.

So, there will be an adaption cost, but I’m optimistic it will be low, given our starting point. Over time I’ll reflect on how it went.


Screenshot of Rocketchat with previous Slack historty loaded

Hey Ton, ik heb al meer goeds gehoord over Rocketchat als vervanger van Slack. Wat me bij deze diensten toch erg interesseert is de kosten van overstap voor de overige gebruikers. Met name de mentale overstap. Ik kan me voorstellen dat je huidige conversatiepartners in Slack zelf ook meer Slack-koppelingen hebben.

Frank Meeuwsen

Rocketchat looks rather good as a Slack replacement! Open source, data on our own server. It has an import function for Slack exports so now that we have set up our own rocket chat server (named slack to make the switch easy on the mind), I’m importing all our Slack content over. Much better than staying with Slack which at our current usage level runs at about 75 Euro / month, whereas our managed hosting solution is 12 Euro / month including a 1 hr SLA response time. It integrates with our cloud, allowing direct drag and drop of any files.