Can someone explain in layman terms what Rocket.Chat is? Is it a Matrix client like Element? Is it a protocol?
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.
They could have just created a matrix client instead of the whole business model...
> 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
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.
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.
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.
> 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.
> 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.
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.
> 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.
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).
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.
* 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