Idea: Group Chat Tunneling (Sync) with EH Forwarder Bot

EH Forwarder Bot (EFB) is an extensible chat tunneling framework written in Python 3. GitHub.

EFB is mainly designed for gathering messages from many other platforms to the one platform, but also designed with other types of tunneling in mind. In this article, I’d like to introduce how EFB works now, and how to design channels for group chat tunneling with utilizing available channels in EFB. Here “group chat tunneling” means synchronizing messages across several groups in different platforms.

The classical model of EFB works like the following diagram:

Messages are collected and processed from slave channels, sent through the EFB framework to the master channel, and finally to the user. In order to ensure high compatibility among different platforms, the message is converted to the general EFBMsg object, parsed by respective channels, and then sent to the other platform by the respective channels.

While for group chat tunneling, it’s a little bit different. When a message is sent from one channel, it should be delivered to all other channels, instead of just one on the other end. So, instead of having one chat platform as the master channel, we can have a specially designed module as the master channel, and let it process and dispatch messages.

As we can see from the documentation, a master channel can get messages from slave channels and send messages to slave channels. Utilizing this feature, the “Group tunneling” master channel can fit the purpose of synchronizing messages among them.

A simple outline of the workflow of a slave channel can be like this:

1. Slave channel collects message from the corresponding platform, parses it to an EFB Message object, and enqueue it to the global message queue
2. Group Tunneling Master (GTM) collects message from the global message queue, and attach the sender’s identifier to the message text.
3. GTM finds a list of corresponding slave channels and chats for it to deliver the message.
4. It collected through all the recipient slave channels for their supported message types, and check if the incoming message fits it.
   • If the incoming message type does not fit into any of the recipient channels, the message is converted to the fallback messages type — text message, for consistent delivery.
   • For example, multimedia messages can be uploaded to servers, and a link to the corresponding file can be sent in a text message, with possibly some descriptions of the file (media type, file name, size, duration, MIME types, etc.)
   • Furthermore, you can also create a fallback message type tree while dealing with unsupported message types. A possible fallback tree is provided in the appendix.
5. When all fallback mechanism is finished, GTM can now call the send_message method of each channel.
6. All recipient slave channels process and send messages to their platforms.

Admin panel

Unlike other ordinary channels that interact with user through the chat platform, GTM does not directly interact with any chat platform, thus it has to build its own interface to interact with user, be it web, CLI or or native GUI (not recommended as most users run EFB on VPS where GUI is hardly found).

Examples of some features offered by the admin panel

• Tunneled chat grouping
• Message type/sender filtering
• Advanced filtering
• Third-party media hosting
• Fallback behaviors for un-tunneled chats

Note that this is just a non-exhaustive list of possible features, you may always include any other feature that fits your need.

So this is just an idea, explaining one of the ways you can make a group chat tunnel with EFB framework. If you have any better idea, or you’ve met any issue in using or building with EFB, you’re always welcomed to comment below, or join the support group on Gitter or Telegram. (Links available in GitHub Repo).

Appendix: A possible fallback message type tree