Welcoming Rocket.Chat to Matrix | Hacker News Reader

Welcoming Rocket.Chat to Matrix

matrix.org

221 pointsanthropodie77 comments

Rocket.Chat uses their own E2EE scheme [1] which is different and arguably less secure than the one in Matrix [2]. As I understand it, this is simply a bridge and will defeat the purpose of the advanced E2EE algorithm in Matrix. I recall looking at Rocket.Chat when setting up chat servers for my corporation and dropping it over their poor and slow to adopt E2EE implementations.

[1] https://docs.rocket.chat/guides/security/end-to-end-encrypti...

[2] https://gitlab.matrix.org/matrix-org/olm

That's also the reason you cannot securely message Matrix users if you already have a XMPP address.

Even if Rocket.Chat used the same E2EE scheme as Matrix, you would still have to re-encrypt, given the application-layer protocols are not the same. RC's messages are a blob of JSON which looks nothing like Matrix's JSON events. To preserve E2EE throughout you'd have to speak precisely the same protocol - e.g. Matrix+Megolm or XMPP+OMEMO or whatever, or effectively run a multihead stack (one which can speak both Matrix & Rocket.Chat), which isn't exactly elegant.

This is the disadvantage of bridges, alas: if you want E2EE, you need to be on the same protocol throughout.

You can run bridges on the client, but that is not well supported right now.

True, although this is one step away from being a multihead messenger, effectively. It's just that the protocol-specific modules are daemons using a standard API rather than in-process.

For instance, I can't think of a way that one would run an Element Web<->Rocket.Chat bridge clientside, as web browsers can't use local web services, short of a service worker... but by the time you're running a dedicated service-worker for a webapp which lets it talk to another webapp, it's basically become a multihead msgr.

I believe the eventual intention is to run a bridge in the client, allowing for perfect secrecy. Matrix itself is showing signs of running a homeserver on every client (though that's still experimental). Both projects are still a long way away, though.

To be fair, though E2EE is perfect for a general purpose messenger, I don't think it's necessary per se. Group chats that would normally appear on IRC don't have a need for E2EE (and verifying everyone in a public room is also extremely impractical!) which seems like a perfect use case for this integration.

The other day, 82 comments

https://news.ycombinator.com/item?id=31535034

This post is a bit different, given it's actually giving the technical details and linking to the howto etc :)

Let's hope Rocket.Chat don't limit federation but use/allow open federation to all Matrix servers and also use and enable the XMPP bridge too. This will give both protocols a boost. Btw: Will they drop the "old" federation?

https://www.freie-messenger.de/en/sys_team/#rocket-chat

I tried to run rocket chat behind nginx, Android mobile clients updated correctly for a few minutes after original sync, and then it would break and remain broken unless I restarted rocket chat.

Desktop web clients worked always.

It's probably a websockets issue.

I tried running behind haproxy and traefik, same problem.

I tried following some advice I got from a maintainer in their forums, same problem.

I went back to Mattermost.

Is a shame, rocket chat UI seems nicer to me than mattermost

Sounds exactly like a websocket issue. Typically a matter of making sure you have the right options on the proxy block.

Here is a recent example for nginx that handles websockets: https://github.com/geekgonecrazy/rocketchat-matrix-federatio...

Can someone explain in layman terms what Rocket.Chat is? Is it a Matrix client like Element? Is it a protocol?

Rocket.Chat is basically selfhosted slack.

They now have a feature where it can federate with matrix. This means rocketchat users on your rocketchat instance can talk to matrix users on a federated matrix network if you enable it.

This means you could use the Rocket.chat server and Rocket.chat UI as an alternative to a homeserver + matrix client.

I don't believe this allows using a matrix client to connect to rocket.chat server's directly or vice versa.

Thanks! So they have their own protocol and client. But, they have made a bridge with matrix.

They could have just created a matrix client instead of the whole business model...

Matrix was still a part of Amdocs and basically not a thing beyond a protocol and a WebRTC demo When RocketChat was created.

Well, matrix is from 2014, rocketchat from 2015. I don't know if matrix was this popular and mature in 2014 to adopt it to build a business around it.

At the end of the article they posted an update:

> Aaron from Rocket.Chat just published an excellent guide & video tour for how to actually set up your Rocket.Chat instance with Dendrite

Dendrite is a Matrix homeserver[1] so it looks like you can mix and match

[1]: https://matrix.org/docs/projects/try-matrix-now#servers

> Rocket.Chat is basically selfhosted slack.

What would this accomplish that self hosting synapse doesn't?

It's totally possible to self host the official matrix 'synapse' daemon for self hosted slack-like functionality within an organization, and use the official 'element' client or any other compliant matrix protocol client. If it's for something like company slack-like functionality you can choose to federate or not federate.

https://github.com/matrix-org/synapse

I have one setup where the synapse daemon lives on a VM that's only accessible in company internal RFC1918 IP space so you can only connect to it if your laptop or other device is also on a split tunnel VPN.

Of course you could run it with a public IP as well.

> What would this accomplish that self hosting synapse doesn't?

It would have all your messages in it if you've been using it for years.

You may prefer the UI.

It may be more efficient (synapse gets a lot of bad press for being heavyweight).

You may partner with a company that already has one system, while you use the other, and would like to chat with each other without either of you changing out your infrastructure.

> It's totally possible to self host the official matrix 'synapse' daemon for self hosted slack-like functionality within an organization, and use the official 'element' client or any other compliant matrix protocol client. If it's for something like company slack-like functionality you can choose to federate or not federate.

Having attempted to do exactly this recently, let me assure you that while it may be technically possible, it is practically infeasible.

Almost everything in Matrix, at multiple layer of abstraction, is built on the presumption of federation: federated events, federated authn/authz, etc. Try to turn federation off, and you're in a no-man's land of untested and unpredictable behaviors. Want to turn off federation _and_ make E2EE obligatory? Good luck! Even if you manage to get Synapse configured to work that way, you'll be delighted to discover that retention rules don't apply to encrypted events.

Synapse, by the way, is a real resource hog. It used an order of magnitude more resources than any other service in my entire infrastructure _at idle_ with no users and no federation. I would have loved to use one of the alternative server implementations, but none of them supported both E2EE and SSO.

Matrix is a dead-end.

What? Almost every statement here is wrong. There are tonnes of unfederated Matrix servers out there, and E2EE and SSO is completely orthogonal to federation. History retention does apply to encrypted events. And Synapse only tends to use lots of resources when federated into large public rooms (these days). I’m terrified at what must have gone wrong such that you ended up drawing these conclusions :s

I'm conveying my personal experience with the software.

> There are tonnes of unfederated Matrix servers out there,

No way to know for sure, but it certainly isn't a well-supported configuration.

> History retention does apply to encrypted events.

> Note that message retention policies don't apply to state events.

https://github.com/matrix-org/synapse/blob/develop/docs/mess...

> And Synapse only tends to use lots of resources when federated into large public rooms (these days)

Synapse used 30-50% of 1 CPU and ~1GB memory at idle with 1 room and 0 connected clients.

> > There are tonnes of unfederated Matrix servers out there,

> No way to know for sure, but it certainly isn't a well-supported configuration

It really is. By default we develop against unfederated servers (synapse running on localhost). Of the synapses we host at EMS probably 30% are unfederated. It is completely supported.

> Note that message retention policies don't apply to state events

Correct. State events are key/value data associated with a room - eg who’s in it, what it’s called, whether it’s encrypted. obviously you can’t expire them after N days otherwise the structure of the room would disintegrate. It has nothing to do with E2EE messages.

> Synapse used 30-50% of 1 CPU and ~1GB memory at idle with 1 room and 0 connected clients.

Then something was going really weirdly wrong. It should idle at <1% cpu and ~150MB RAM on an unfederated server with one room and zero clients.

Very strange.

Here are a few tips to reduce resource consumption (german): https://www.freie-messenger.de/en/sys_matrix/#eigener-server

> Correct. State events are key/value data associated with a room - eg who’s in it, what it’s called, whether it’s encrypted. obviously you can’t expire them after N days otherwise the structure of the room would disintegrate. It has nothing to do with E2EE messages.

E2EE-encrypted message are persisted by Synapse as state events.

Or, maybe more precisely, if I set a message retention policy of X days, rows in event tables associated with E2EE-encrypted rooms, which are created when messages are sent to that room, and which are older than X days, are not removed.

> it is practically infeasible.

> Try to turn federation off, and you're in a no-man's land of untested and unpredictable behaviors.

This is wrong. I have been using non federated server for over a year and I hardly faced any issue.

Similar to Slack, but open source

Rocket.Chat is an opensource team collaboration and omnichannel product. Its team collaboration features would be of the likes of slack / discord etc. The omnichannel features bring in different customer facing channels like facebook/twitter/instagram/whatsapp/telegram/livechat/etc into the tool.

Matrix is a protocol with a primary focus on federation. Rocket.Chat is basically adopting the Matrix Protocol to bring Federation into the product. This means that two Rocket.Chat servers from two different companies on their respective infrastructure can now talk to each other. Or even if you are on Rocket.Chat and want communicate with another company that is using Element(the client developed the same people that are developing the Matrix Protocol).

rocketchat already had federation, but it is/was awful

It definitely was still in its infancy. But I think this is where Rocket.Chat's decision makes tons of sense. Matrix has spent as many years I think as Rocket.Chat focusing on a protocol. So makes perfect sense to leverage all of that time and learnings.

Not to mention it means Federation with anyone that chooses to implement this common protocol. So beyond business interest alone but contributing to the greater ecosystem hopefully.

Well that thought came out incomplete.

* Matrix has spent as many years I think as Rocket.Chat —> * Matrix has been around about as long as Rocket.Chat but focused heavily on federation

Rocket.Chat is made for workgroups (“groupware”) and can be seen as open source alternative to “Slack”. Open source teammessengers are Matrix, Mattermost, Rocket.Chat and Zulip:

https://www.freie-messenger.de/en/sys_team

This is what a aquisition in Open Source land looks like.. :D

Gee, I wonder who acquired Fediverse then - everyone's speaking ActivityPub.

As someone curious about this comment, can you articulate it in a way that would work in spoken words? the /s throws it off, like when people speak verbal hashtags, and my brain flies into the wall at velocity trying to break it down.

No one could/did acquire the Fediverse, there's just a protocol in common between pleroma/mastodon/misskey and so on.

The thread's topic is likely similar, Matrix being another protocol used by many things.

The sibling comment described it well. Adding support for an open networking protocol to an existing free software application is, IMO, hardly an acquisition of any sort - not more than e.g. adding support for a new image format to GIMP means that "owners" of the new format now acquire GIMP.

I don't think this is an acquisition -- Rocket.Chat remains an independent, venture-backed company. Unless I'm missing something hidden here, this announcement is just Rocket.Chat implementing an integration with Matrix, not a change in control of their open source project or associated business.

Yup, this is not an acquisition of any kind; Rocket.Chat just went and independently added native Matrix interoperability into their core product. It's basically celebrating this PR: https://github.com/RocketChat/Rocket.Chat/pull/23688 :)

tabbott: we should so do this with Zulip - I think Matrix almost has all the threading primitives needed to bridge successfully now!

Yeah let's chat about it! We've overdue for catching up in any case :)

Wasn't the work (not the result) "announced" already during FOSDEM 1.5 years ago? Real world moving more slowly? Just an observation, it happens to all of us...

hm, i don’t remember announcing anything on the Matrix side? i might have namedropped that we’d been discussing it as a possibility tho!

I don't remember the wording. But something that there had been discussions and it should not be difficult / much work.

I think that is what they mean—the 'acquisition' in Open Source land is just the successful integration of one open platform into the other!

A new implementation of the same thing, now on a different platform.

Is it just me or does it seem like there are certain places where there is little innovation?

We must return to AIM.

You can only reinvent text chat in so many ways before you converge to the de-facto standard most people are using nowadays.

If the goal is simple text chat (communication that uses text) - but text can be used in a wide variety of ways!

If some of the many who have reimplemented the same thing on a new platform instead set out to create something new, maybe something new would appear on the scene.

> If some of the many who have reimplemented the same thing on a new platform instead set out to create something new, maybe something new would appear on the scene.

They do, and novelties do appear. But then they usually fail to gain traction because they require users to migrate to them. Hence, interoperability wins in the long run.

Can you think of any particularly impressive and innovative text-related communication platforms (ruling out impressive ones like Zoom that aren't textually innovative) that have been released in the last 5 years?

I'd argue basic chat functionality is a solved problem, and if Rocket.Chat deprecates their need to build and support that, they can focus entirely on value add/innovation.

I wonder how this will effect Riot, now Element

There are multiple chat clients that support Matrix already [1], Element is just one of them. Separation of concerns is a good thing as products mature

[1]: https://matrix.org/clients/

The question was due to the tight relationship between the two, not due to a misunderstanding. Im a daily user of Matrix, many clients.

I see, my mistake. The coupling is definitely tight. I think the developers across Matrix and Element are largely the same too right? Ideally I would hope that the Matrix team can focus on the protocol, but I can see why they needed to build Element as a way to sell the protocol to the masses. But perhaps now that we have fully-featured front-ends like Rocket chat joining in, the Matrix team can dedicate more of them time to the protocol

I suspect the market is different enough to matter. Rocket.Chat caters heavily to the Slack/Teams-type business chat. Federation to it likely often means federating with partner businesses also using Rocket.Chat.

Element targets individuals participating largely in public chat rooms, I suspect it's design will remain significantly different for that reason.

Different apps with different purposes, but compatible.

I wouldnt count Element as a single-user only offering, as there is significant effort on enterprise as [its*] source of income. https://element.io/enterprise-collaboration

Looks great. Never heard before about rocket chat. Has anybody tried getting video calls working on it?

HN frequently seems obsessed with Matrix. So I want to ask, where do you all hang out and how do you use it? I think Matrix is cool, I just am not sure how people are actually using it.

Please don't tell me to look at the channels list there's a lot of porn and most channels I have joined are dead.

I don't use it often but I'm a big fan. I think just like how you don't look up whether someone is using outlook or gmail when you want to email them, IM and video calls should not be bound to clients. It's stupid that I need MS Teams to talk to someone, when all my stuff are on another platform. Matrix is fixing that.

I use it as a one-stop-shop for messaging. I setup a Synapse server ~5 years ago and since then have convinced many of my close family and friends to join my server (or another). Now many of the folks I want to chat with are regular users of Matrix. For some of my stone-age friends that are still on WhatsApp, I run a bridge [1] so that I don't need to look beyond my Matrix client to see WhatsApp messages. For other random SMS messages, I use the dated SmsMatrix [2] to push text messages so I can see/reply from Matrix. Beyond that, I also use Matrix to connect to several open source communities (e.g. Mailu.io [3]).

1. https://github.com/mautrix/whatsapp 2. https://github.com/tijder/SmsMatrix 3. https://matrix.to/#/!RJFCFtixHgPhzacdhW:tedomum.net?via=ghos...

This seems like the best answer, but I already did that switch with most people and Signal (took years to grow that network). But I do like the idea of bridges for WA and SMS (I know there is a Signal bridge too)

It's a battle-tested open source Discord/Slack/etc replacement with sound 1-on-1/group chat E2EE encryption. It's like Facebook Messenger:Signal as Slack:Matrix, and it's easy to use software even for people not familiar with dealing with the ins and outs of complicated cryptosystems. Unlike Signal it has always been completely open source.

> Unlike Signal it has always been completely open source.

Honest question: when was Signal closed source, as Signal? I’m not familiar with this. I know it’s roots are in the old Moxie Marlinspike OpenWhisper apps, but that’s a long time ago and the last I looked, Signal open sourced all their code.

There's gripe from people because they didn't update the GitHub repos for the server code for a bit. Client side code was always up to date. There's also another complaint (imo this one is more legitimate) that Signal only allows messages to be passed through their servers. I don't think the parent is really arguing in good faith tbh.

For a year

There has been a lack of transparency with their server code. Very late pushes (>1 year) when they were adding their cryptocurrency, and now some black box code to "eliminate spam" [2]. By contrast, Matrix has always had master public and allows users to run their own servers either privately or connected to the federation, something not really possible with the Signal app family.

[1] https://news.ycombinator.com/item?id=26345937

[2] https://www.reddit.com/r/privacy/comments/qlw1ag/signal_is_a...

LMAO "battle-tested" that's one way to describe that Meteor.js pile of junk. I'll never forget that time one of my users on my small Rocket Chat server two or three years ago changed their username and it not only immediately crashed the server but also corrupted the database because the change had to check every message ever sent for that user in the database because they didn't put an index on an immutable ID. I had to write a program to manually remediate the data in order to get our chat back online.

Don't get me started on the mobile app. I have so many stories of pain from Rocket Chat that it isn't funny.

I then spent several months writing a bespoke application to extract my community from RocketChat and move it to a different product because it was so terrible.

Now, I stopped using it in 2019 but had used it for the prior four years every single day and it only got worse with every release. I used to joke to my friends "what new bugs will this release have?" until the mobile app rewrite became so unbearable that it almost killed my community entirely.

Is it better now? Well, I bet it has more half baked features, like Matrix integration I guess. Rocket Chat always looked great on paper... Just don't try to use it too much, or look at the code.

I was referring to Matrix suite, not Rocket.Chat. I've never used Rocket.Chat so I can't comment on that. :)

The public room list is generally considered a bad idea, and we're seriously considering deprecating it in favour of space hierarchies - i.e. curated hierarchies of groups of rooms, so that folks who like curating lists of interesting rooms can go and do so - rather than them all being dumped in a huge mess in a linear list. There'd then be social pressure to curate the best space index, rather than it being a tragedy of the commons of random lost forgotten rooms.

In terms of where to hang out and where to use it, here are some handy spaces picked from my personal space bar...

* https://matrix.to/#/#community:matrix.org <-- rooms about Matrix itself

* https://matrix.to/#/#space:ansible.com <-- rooms about Ansible

* https://matrix.to/#/#activitypub-community:codelutin.com <-- rooms about Activity Pub

* https://matrix.to/#/#wikimedia-space:matrix.org <-- rooms about the Wikimedia community

* https://matrix.to/#/#solarpunks:solarpunk.cloud <-- a random solarpunk community i lurk in...

* https://matrix.to/#/#rlang:matrix.org <-- rooms about the R language

* https://matrix.to/#/#buddies-of-budgie:matrix.org <-- rooms about the Budgie desktop environment

etc etc. This ends up being way higher signal-to-noise than the room list (although there's always the risk that a space will get forgotten and neglected).

Obviously this selection is biased a bit towards open source software, given that's what I'm into, but there are loads of other communities too. Nobody's yet started a big global space tree to help find them (probably because subspace performance needs some work), so the best bet for discovering them otherwise is probably simply through DDG or Google or whatever, looking for folks advertising them on their websites.

Alternatively, you can head off into IRC or some other Matrix server (e.g. mozilla.org) from the room directory selector in your matrix client of choice. Many of my rooms are actually bridged into IRC, XMPP, Slack, Discord etc rather than entirely native Matrix.

I hang out in a ton of FOSS projects' rooms / bridged IRC channels / other rooms I saw mentioned in discussion. I use it to give and receive support, to learn, and as an occasional break from work.

https://view.matrix.org is a good list, at least the first few pages seemed SFW, most populous rooms are first, and you can search by keyword.

Once you get into the main room of any large community, check the topic or ask if there's a Space, which gives an organized overview of a community's rooms (in a featureful matrix client like Element).

I've been using it in daily chats with friends, and with my gaming groups, for about two years. The end-to-end encrypted, Google-free comms have elevated the quality of our online conversations: We no longer feel the need to self-censor, so we talk more freely about personal matters. When I noticed this, it felt like an invisible weight I had been carrying for ages was finally gone.

I'm avoiding public rooms until my Matrix clients support multiple accounts/identities, so open source chats are still on an irc client for now.

Matrix is where open source projects move their chat rooms when they don't actually want public input.

As a maintainer of an open source project, we moved to matrix when freenode imploded and so we could bridge our users (mostly on discord) into the same room with our developers many of whom refused to use discord on principle.

I didn't know Rocket.Chat, but it looks like a decent OpenSource alternative to Slack. The fact they are switching to Matrix seems like a bigger win to Matrix than Rocket.Chat.

Rocket.Chat is a real world chat client that seems to have some success and they just decided to delegate an important part of their stack to a third party project. What better validation do you expect than that?

In this case it isn't really "switching" to Matrix. Its more Rocket.Chat is utilizing Matrix to increase chances of interoperabilty.

Rocket.Chat still maintains its own full frontend and backend. With its own API's and integrations etc. But gains a new ability to communicate with anyone out there also using the Matrix protocol. Regardless of what Software they are running.

So say your company has Rocket.Chat running and then you start working on a project with another company. You can create federated rooms and collaborate.

IMO its very much a strategic advantage to have federation support in your tool.

I personally view this as an important move for the future of the internet and modern decentralized communication.

%1000 this. I have tried RocketChat before and loved its ease of use and powerful well-polished features! But, I ultimatly was scared off because I did not want to get locked into a walled garden (even if the garden was self-hosted...). Federation is hugely important for communication.

Reply on news.ycombinator.com