[HN Gopher] Welcoming Rocket.Chat to Matrix
___________________________________________________________________
Welcoming Rocket.Chat to Matrix
Author : anthropodie
Score : 197 points
Date : 2022-05-31 16:39 UTC (6 hours ago)
(HTM) web link (matrix.org)
(TXT) w3m dump (matrix.org)
| dudus wrote:
| 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?
| geekgonecrazy wrote:
| 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.
| jlkuester7 wrote:
| %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.
| mistermann wrote:
| 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?
| phoe-krk wrote:
| You can only reinvent text chat in so many ways before you
| converge to the de-facto standard most people are using
| nowadays.
| ocdtrekkie wrote:
| 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.
| 0des wrote:
| I wonder how this will effect Riot, now Element
| woojoo666 wrote:
| 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/
| 0des wrote:
| The question was due to the tight relationship between
| the two, not due to a misunderstanding. Im a daily user
| of Matrix, many clients.
| woojoo666 wrote:
| 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
| ocdtrekkie wrote:
| 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.
| 0des wrote:
| 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
| 0des wrote:
| We must return to AIM.
| tasubotadas wrote:
| Looks great. Never heard before about rocket chat. Has anybody
| tried getting video calls working on it?
| [deleted]
| f38zf5vdt wrote:
| 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
| Arathorn wrote:
| 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.
| jeroenhd wrote:
| 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.
| CameronNemo wrote:
| You can run bridges on the client, but that is not well
| supported right now.
| Arathorn wrote:
| 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.
| zaik wrote:
| That's also the reason you cannot securely message Matrix users
| if you already have a XMPP address.
| ramboldio wrote:
| This is what a aquisition in Open Source land looks like.. :D
| phoe-krk wrote:
| Gee, I wonder who acquired Fediverse then - everyone's speaking
| ActivityPub.
|
| /s
| 0des wrote:
| 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.
| opan wrote:
| 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.
| phoe-krk wrote:
| 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.
| tabbott wrote:
| 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.
| Arathorn wrote:
| 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!
| tabbott wrote:
| Yeah let's chat about it! We've overdue for catching up in
| any case :)
| usr1106 wrote:
| 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...
| Rechtsstaat wrote:
| 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!
| godelski wrote:
| 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.
| jlkuester7 wrote:
| 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...
| godelski wrote:
| 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)
| Arathorn wrote:
| 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.
| f38zf5vdt wrote:
| 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.
| TheNewsIsHere wrote:
| > 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.
| godelski wrote:
| 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.
| f38zf5vdt wrote:
| 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...
| mdmdlslau wrote:
| 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.
| f38zf5vdt wrote:
| I was referring to Matrix suite, not Rocket.Chat. I've
| never used Rocket.Chat so I can't comment on that. :)
| simonmic wrote:
| 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).
| superkuh wrote:
| Matrix is where open source projects move their chat rooms when
| they don't actually want public input.
| a1371 wrote:
| 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.
| [deleted]
| foresto wrote:
| 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.
| pvg wrote:
| The other day, 82 comments
|
| https://news.ycombinator.com/item?id=31535034
| Arathorn wrote:
| This post is a bit different, given it's actually giving the
| technical details and linking to the howto etc :)
| [deleted]
| ducktective wrote:
| Can someone explain in layman terms what Rocket.Chat is? Is it a
| Matrix client like Element? Is it a protocol?
| Macha wrote:
| 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.
| walrus01 wrote:
| > 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.
| preseinger wrote:
| > 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.
| Macha wrote:
| > 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.
| ducktective wrote:
| 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...
| zufallsheld wrote:
| 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.
| SargeZT wrote:
| Matrix was still a part of Amdocs and basically not a thing
| beyond a protocol and a WebRTC demo When RocketChat was
| created.
| woojoo666 wrote:
| 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
| savy91 wrote:
| Similar to Slack, but open source
| geekgonecrazy wrote:
| 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).
| tuerai wrote:
| rocketchat already had federation, but it is/was awful
| geekgonecrazy wrote:
| 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.
___________________________________________________________________
(page generated 2022-05-31 23:01 UTC)