5 ms·
Can someone explain in layman terms what Rocket.Chat is? Is it a Matrix client like Element? Is it a protocol?
by ducktective 4y ago
Can someone explain in layman terms what Rocket.Chat is? Is it a Matrix client like Element? Is it a protocol?
- Macha 4y agoRocket.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.
- ducktective 4y agoThanks! 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...
- SargeZT 4y agoMatrix was still a part of Amdocs and basically not a thing beyond a protocol and a WebRTC demo When RocketChat was created.
- zufallsheld 4y agoWell, 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.
- woojoo666 4y agoAt 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 https://matrix.org/docs/projects/try-matrix-now#servers
- walrus01 4y ago> 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 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.
- Macha 4y ago> 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.
- preseinger 4y ago> 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.
- savy91 4y agoSimilar to Slack, but open source
- geekgonecrazy 4y agoRocket.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 4y agorocketchat already had federation, but it is/was awful
- geekgonecrazy 4y agoIt 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.
- geekgonecrazy 4y agoWell 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
- Freie_Messenger 4y agoRocket.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 https://www.freie-messenger.de/en/sys_team