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.
👍
Good on you! @edgeryders is on matrix.org for the same reasons.
Just wondering, did you consider zulip?
@ton Same, and it’s easy to run too.
No, haven’t looked at zulip. Do you have any experience with it?
No, considering, that’s why I am asking. Thanks!
This Article was mentioned on Van Slack naar Rocket.chat – Roel.io
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.
Wednesday it was 18 years ago that I first posted in this space. The pace of writing has varied over the years, obviously intensively at the start, and in the past 3 years I have been blogging much more frequently again (with a correlated drop off in my Facebook activity to 0), more than at the start even.
This year is of course different, with most of the people I know globally living much more hyper local lives due to pandemic lockdowns. This past year of blogging turned out more introspective as a consequence. In the past few years I took the anniversary of this blog to reflect on how to raise awareness for grasping your own agency and autonomy online, and reading last year‘s it’s so full of activity from our current perspective, organising events, going places. None of that was possible really this year. I returned home from the French Alps late February and since then haven’t seen much more than my work space at home, and the changing of the seasons in the park around the corner, punctuated only with a half dozen brief visits to Amsterdam and two or three to Utrecht in the past 8 months. A habit of travel has morphed into having the world expedited to our doorstep, in cardboard packaging in the back of delivery vans.
Likewise my ongoing efforts and thinking concerning networked agency, distributed digital transformation and ethics as a practice has had a more inward looking character.
Early in the year we completed the shift of my company’s internal systems to self-hosted Nextcloud and Rocket.chat. When the pandemic started we added our own Jitsi server for video conferencing, although in practice with larger groups we use Zoom mostly, next to the systems our clients rolled out (MS Teams mostly). Similarly I will soon have completed the move of the Dutch Creative Commons chapter, where I’m a board member, to Nextcloud as well. That way the tools we use align better with our stated mission and values.
I spent considerable time renovating my PKM system, and the tools supporting it, with Obsidian the biggest change in tooling underneath that system since a decade or so. It means I am now finally getting away from using Evernote. Although I haven’t figured out yet what to do, if anything, with what I stored in Evernote in the 10 years I’ve been using it daily.
This spring I left Facebook and Whatsapp completely (I’ve never used Instagram), not wanting to have anything to do anymore with the Facebook company. I departed from my original FB account 3 years ago, which led to me blogging much more again, but created a new account after a while to maintain a link to some. That new account slowly but steadily crept back into the ‘dull’ moments of the day, and when the pandemic increased the noise and hysterics levels aided by FB’s algorithmic amplification outrage machine, I decided enough was enough. A 2.5 year process! It more or less shows how high the, mostly misplaced, sense of cost of leaving can be. And it was also surprising how some take such a step as an act of personal rejection.
I also see my Twitter usage reducing, in favour of interacting more on my personal Mastodon instance, through e-mail (yay for e-mail) and LinkedIn (where your interaction is tied to your professional reputation so much less of a ragefest). Even though I never dip into the actual Twitter stream, as I only check Twitter using Tweetdeck to keep track of specific topics, groups and interests. This summer I from close-up saw how the trolls came for a colleague that moved to a position in national media. Even if the trolling and vitriol was perhaps mild by e.g. US standards, it made me realise again how there was an ocean of toxic interaction just a single click away from where I usually am on Twitter.
On the IndieWeb side of things, I of course did not get to organise new IndieWebCamps like last year in Amsterdam and Utrecht. I’ve thought about doing some online events, but my energy flowed elsewhere. I’ve looked more inwardly here as well. I’ve been bringing my presentation slides ‘home’, closing my Slideshare account, and removing my company from Scribd as well. This is a still ongoing process. The solution is now clear and functional, but moving over the few hundred documents is something that will take a bit of time. I don’t want to move over the bulk of 14 years of shared slide decks, but want to curate the collection down to those that are relevant still, and those that were published in my blog posts at the time.
I am tinkering with a version of this site that isn’t ‘stream’ (blogposts in reverse chronological order), and isn’t predominantly ‘garden’ (wiki-style pseudo-static content), but a mix of it. I’ve been treating different types of content here differently for some time already. A lot never is shown on the front page. Some posts are never distributed through RSS, while some others are only distributed through RSS and unlisted on the site (my week notes for instance). Now I am working on removing what is so clearly a weblog interface from the front page. The content will still be there of course, the RSS feeds will keep feeding, all the URLs will keep working, but the front of this site I think should morph into something that is much more a mix of daily changes and highlighted fixtures. Reflecting my current spectrum of interests more broadly, and providing a sense of exploration, as well as the daily observations and occurrences.
Making such a change to the site is also to introduce a bit of friction, of a need to spend time to be able to get to know the perspectives I share here if you newly arrive here. I think that there should be increased friction with increased social distance. You’ll know me better if you spend time here. The Twitter trolling example above is a case of unwanted assymmetry in my eyes: it’s incredibly easy for total strangers to lob emotion-grenades at someone, low cost for them, potentially high-impact for the receiver. Getting within ‘striking distance’ of someone should carry a cost and risk for the other party as well. A mutuality, to phrase it more constructively.
Here’s to another year of blogging and such mutuality. My feed reader brings me daily input from so many of you, around the world, and I’m looking forward to many more distributed conversations based on that. Thank you for reading!