Federation Protocol

[valentt]

Hi, first this as awesome chat, so far best I have used.

Have you considered creating Rocket.Chat so it can be decentralised but also federated with cluster of multiple Rocket.Chat servers ?

Use case:
Having branch offices offices around the world (or distributed islands of community wireless networks in our case) that each would run their own Rocket.Chat server but they would be part of one Rocket.Chat network so that any client connected to any servers sees all users and all rooms.

So if for some reason connectivity breaks (which happens more than we would like) clients at least have their own local server, and when connectivity is back then they join back with the rest of the Rocket.Chat network.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[rodrigok]

This is very complex 😄 hehe

[valentt]

I would love to use Rocker.Chat instead of IRC and Jabber, and this is exactly how they are used. Probably needs a quite bit work on abstraction... and no, it definitely is not easy :)

[mitar]

You can always just decentralize MongoDB server.

[engelgabriel]

Maybe implement the http://matrix.org/ spec?

[geekgonecrazy]

This would be pretty cool. Might be good to take a look at this while working to make it play well in cluster / load balancing situations. #520

[GrahamJenkins]

I'd like to add a sub feature request, it could be moved to a separate request depending on the maintainer's opinions.
I have a use case where several geographically oriented teams need to be able to manage their own teams/servers independently, however they want to share specific content with other teams/servers. If using Slack it is possible through integrations to use services such as sameroom.io or various other bridges, but it would be very helpful if it was possible to configure independent servers to sync/share defined content with other servers, or perhaps even a level of public sharing of specified content.
A feature like this would provide some functionality and ease of use similar to that of account-based tools such as skype, hangouts, etc, but still allow for the operation and administration of independent servers. I would be glad to discuss the potential use cases in more detail if that can clarify/help this request.

[engelgabriel]

I understand your request @rendezvousIY , that's exactly what I believe we will be able to do if we implement this features. We plan to start taking a look at this after we release the 1.0

[engelgabriel]

Hi @ara4n any thoughts on this one? Your input would be much appreciated.

[illicitonion]

Hi @engelgabriel! I work with @ara4n on matrix.org, and I've been taking a look around your Rocket.Chat world - it looks like Hubot is a great match for our node bridging library: https://github.com/matrix-org/matrix-appservice-bridge

We have a one-page example for a basic matrix-slack bridge https://github.com/matrix-org/matrix-appservice-bridge/blob/master/HOWTO.md - I imagine putting together a hubot script which sends every message it sees to a Matrix room, and which sends every Matrix message it sees to a Rocket.Chat room, would be pretty trivial.

If someone put together that bridge, chats could automatically become part of the federated Matrix world which would both open up to users of the systems people are writing Matrix bridges for (we have made usable progress on bridging Slack, IRC, Skype, and a few other things).

We'd love to work with you on this; I'd suggest you take a look at the one page HOWTO above, and see if you can get a quick Hubot script able to just send raw text messages both ways. From there, we can have a chat about where we may want to go.

Feel free to reply here, drop me an email (daniel@matrix.org), or come stop by a Matrix room (I just made #rocketchat:matrix.org which you can talk at by using https://matrix.org/blog/try-matrix-now/ ) if you need a hand with anything, or want to chat!

[engelgabriel]

Hi @illicitonion

Thanks for the reply, I'll take a look at your links. I think it would be a nice first step, so lets do that, but my end goal would be to create a "native" capability via meteor package. :)