The following diagram shows an example of Rocket.Chat's federation deployment.
By design, both matrix and rocket.chat servers sit under the same domain.
This is primarily how you can federate from one rocket.chat instance to another.
With matrix, service discovery works via well-known, where a certain path returns the exact path of the homeserver instead of the given path.
In this case, example.com may be the homeserver domain, but the actual url is only given upon hitting https://example.com/.well-known/matrix/server - which would return a subdomain like matrix.example.com:443 (with port).
Let's look at the flow of creating a DM
We have one server alice.rocket.chat with @aaron being one user of that workspace (Rocket.Chat), and another workspace bob.rocket.chat with @debdut being another user.
@aaronrequests a dm with@debdutover atbob.rocket.chat- Rocket.Chat creates a matrix user under
matrix.alice.rocket.chatfor@aaronif can't find one - The bridge asks the homeserver to create a room between two matrix users
@aaron:alice.rocket.chatand@debdut:bob.rocket.chat - Since the matrix homeservers, under the same network are federating with one another, they create the rooms as required
- on
bob.rocket.chatthe homeserver notifies the bridge of the room bob.rocket.chatfinds the internally mapped user for@debdut:bob.rocket.chat- Rocket.Chat creates the internal room and other resources
- Your direct message room kicks off
Here's an example diagram of the flow
