Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Welcoming Rocket.Chat to Matrix

matrix.org

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Welcoming Rocket.Chat to Matrix

#51

Post by foresto »

godelski wrote: post #34

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'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.

Re: Welcoming Rocket.Chat to Matrix

#52

Post by f38zf5vdt »

TheNewsIsHere wrote: post #45
f38zf5vdt wrote: post #42

Earlier quoted context omitted.

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 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...

Re: Welcoming Rocket.Chat to Matrix

#53

Post by Arathorn »

f38zf5vdt wrote: post #37

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/sec…

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.

Re: Welcoming Rocket.Chat to Matrix

#54

Post by mdmdlslau »

f38zf5vdt wrote: post #42
godelski wrote: post #34

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.

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.

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.

Re: Welcoming Rocket.Chat to Matrix

#55

Post by f38zf5vdt »

mdmdlslau wrote: post #54
f38zf5vdt wrote: post #42

Earlier quoted context omitted.

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.

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 ha…

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

Re: Welcoming Rocket.Chat to Matrix

#56

Post by CameronNemo »

Arathorn wrote: post #53
f38zf5vdt wrote: post #37

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/sec…

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 Matr…

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

Re: Welcoming Rocket.Chat to Matrix

#57

Post by godelski »

jlkuester7 wrote: post #40
godelski wrote: post #34

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 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 r…

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)

Re: Welcoming Rocket.Chat to Matrix

#58

Post by phoe-krk »

0des wrote: post #10
phoe-krk wrote: post #4

Earlier quoted context omitted.

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

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.

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.

Re: Welcoming Rocket.Chat to Matrix

#59

Post by preseinger »

walrus01 wrote: post #26
Macha wrote: post #14

Earlier quoted context omitted.

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.…

> 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 n…

> 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.

Re: Welcoming Rocket.Chat to Matrix

#60

Post by Arathorn »

CameronNemo wrote: post #56
Arathorn wrote: post #53

Earlier quoted context omitted.

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 Matr…

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 WebRocket.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.

Post reply on HN