Exploring the Possibility of Using MQTT Protocol in the Turms IM

[visoar]

Turms is an efficient and scalable open-source instant messaging engine, aiming to serve 100K~10M concurrent users. When considering the use of MQTT as an access and communication protocol, we need to take into account the following aspects:

Advantages:

1. Lightweight: MQTT is a lightweight publish/subscribe messaging transport protocol, which is very suitable for use in low bandwidth conditions. This is a significant advantage for instant messaging applications.

2. Quality of Service(QoS): MQTT supports three levels (0,1,2) of message delivery quality of service, including "at most once", "at least once", and "exactly once". This provides great flexibility for instant messaging applications.

3. Topic Filtering: MQTT's topic filtering feature allows clients to receive only the messages they are interested in. In group chat scenarios, this can greatly improve efficiency.

4. Low Power Consumption: The design of the MQTT protocol takes into account the power limitations of mobile devices, making it very suitable for mobile instant messaging applications.

5. Real-Time: The design of the MQTT protocol results in very low latency in message delivery, which is crucial for instant messaging applications.

Disadvantages:

Network Dependence: The MQTT protocol relies on TCP/IP networks, which means that MQTT might encounter problems in unstable network environments.

In conclusion, while MQTT has its advantages, we need to carefully weigh its pros and cons when considering its use in the Turms project. Additionally, we also need to take into account the specific needs and objectives of the Turms project.

Finally, I would like to mention our recently open-sourced BifroMQ.io, a native multi-tenant MQTT broker middleware implementation. If you're interested in MQTT, I suggest you take a look.

[JamesChenX]

Thanks for sharing your idea.

When introducing a feature, we always think what the value it can bring to our users, customers, or employers.
Take a similar protocol as an example, we plan to support XMPP because many people complain Turms never plan to deliver UI for users (yes, that's true because we don't want to limit users' imagination to deliver their own apps) while it will take many efforts for users to write a client application from Turms clients from scratch.
So that's the key reason for us to support XMPP so that users can use many UI-based XMPP clients that are compatible with Turms while we don't need to provide UI implementations.

For MQTT and your project, they are cool, and I know there are some IM projects developed based on MQTT, but I cannot see the MQTT value for Turms in IM scenarios.
(btw, I believe most developers who use MQTT to develop an IM server don't even know what they are doing)

The key value for adapting MQTT to Turms is to support MQTT-based devices, so if someone really thinks it's worthwhile supporting this kind of device, they can implement it by creating a new turms-gateway plugin, e.g. turms-plugin-mqtt, and it's viable but I cannot see MQTT value for Turms, so we have not to plan for it.

---

btw, when discussing technology solutions, ChatGPT usually thinks about things in a naive way (it's a good repeater but not a thinker that can bring out an insight), so if you want to behave professionally in the OSS community, you better don't just copy the answer from ChatGPT for discussions.