sync blogs 2025-01-07-11-03-18

README.md

@@ -205,6 +205,7 @@ Explore more with & via EMQ.
 ## [EMQX Open Source | Broker](https://www.emqx.com/en/blog/category/emqx)
 EMQX is the world's most scalable open-source MQTT broker with a high performance that connects 100M+ IoT devices in 1 cluster, while maintaining 1M message per second throughput and sub-millisecond latency.
 
+- [Quick Start of EMQX MQTT Cloud Service](https://www.emqx.com/en/blog/quick-start-of-emqx-mqtt-cloud-service) ([Edit](https://github.com/emqx/blog/blob/main/en/202501/quick-start-of-emqx-mqtt-cloud-service.md))
 - [Efficient IoT Communication with LoRaWAN & MQTT](https://www.emqx.com/en/blog/lorawan-and-mqtt) ([Edit](https://github.com/emqx/blog/blob/main/en/202411/lorawan-and-mqtt.md))
 - [From Data to Decisions: Building Effective IoT Data Stacks](https://www.emqx.com/en/blog/building-effective-iot-data-stacks) ([Edit](https://github.com/emqx/blog/blob/main/en/202410/building-effective-iot-data-stacks.md))
 - [Stay Connected with No Data Lost: Discover the Power of Durable Sessions in EMQX Platform](https://www.emqx.com/en/blog/emqx-platform-durable-session) ([Edit](https://github.com/emqx/blog/blob/main/en/202410/emqx-platform-durable-session.md))
@@ -392,7 +393,6 @@ The easiest way to start MQTT service. Connect your IoT devices to any cloud wit
 - [The new version of EMQX Cloud realizes multi-project deployment management](https://www.emqx.com/en/blog/emqx-cloud-realizes-multi-project-deployment-management) ([Edit](https://github.com/emqx/blog/blob/main/en/202110/emqx-cloud-realizes-multi-project-deployment-management.md))
 - [EMQX Cloud now officially supports deployment on Google Cloud Platform](https://www.emqx.com/en/blog/introducing-emqx-cloud-on-google-cloud-platform) ([Edit](https://github.com/emqx/blog/blob/main/en/202109/introducing-emqx-cloud-on-google-cloud-platform.md))
 - [Introducing EMQX Cloud on Microsoft Azure](https://www.emqx.com/en/blog/introducing-emqx-cloud-on-microsoft-azure) ([Edit](https://github.com/emqx/blog/blob/main/en/202107/introducing-emqx-cloud-on-microsoft-azure.md))
-- [Quick Start of EMQX MQTT Cloud Service](https://www.emqx.com/en/blog/quick-start-of-emqx-mqtt-cloud-service) ([Edit](https://github.com/emqx/blog/blob/main/en/202107/quick-start-of-emqx-mqtt-cloud-service.md))
 - [Integrate EMQX MQTT Cloud with Home Assistant](https://www.emqx.com/en/blog/integrate-emqx-mqtt-cloud-with-home-assistant) ([Edit](https://github.com/emqx/blog/blob/main/en/202105/integrate-emqx-mqtt-cloud-with-home-assistant.md))
 - [Upload Sensor Data to MQTT Cloud Service via NodeMCU (ESP8266)](https://www.emqx.com/en/blog/upload-sensor-data-to-mqtt-cloud-service-via-nodemcu-esp8266) ([Edit](https://github.com/emqx/blog/blob/main/en/201912/upload-sensor-data-to-mqtt-cloud-service-via-nodemcu-esp8266.md))
 

en/202307/file-transfer-over-mqtt.md

@@ -21,9 +21,9 @@ The result of this effort is a File Transfer over MQTT protocol, which is now av
 
 The File Transfer protocol is designed to be as simple as possible and to be a natural extension of the MQTT protocol. It is based on the MQTT 5.0 specification and uses the same primitives as the base protocol. To support this protocol, a device should know about only a few special topics and reason codes in `PUBACK` packets that provide feedback. Generally, the device needs to send a *command* which is essentially a message published to a special topic, and then wait for the server to respond with a `PUBACK` packet. This `PUBACK` will contain a reason code that indicates whether the broker successfully handled the command. However, this is not a hard requirement, and some dumb devices may choose to ignore the feedback and send commands blindly.
 
-Files are transferred in segments, and each segment is sent as a separate *command*. The broker does not enforce any bounds on the size of the segments, and the device is free to choose any convenient size. The segments do not even have to be of the same size. The device can send them in any order or send the same segment multiple times. The broker should handle all these cases correctly and will reassemble the file on the server side.[^1]
+Files are transferred in segments, and each segment is sent as a separate *command*. The broker does not enforce any bounds on the size of the segments, and the device is free to choose any convenient size. The segments do not even have to be of the same size. The device can send them in any order or send the same segment multiple times. The broker should handle all these cases correctly and will reassemble the file on the server side.
 
-[^1]: However, the broker might take some actions if it thinks that the device is misbehaving. For example, it might limit the total number of segments the device sends for a single file or outright disconnect the device if it sends them in some weird order.
+> However, the broker might take some actions if it thinks that the device is misbehaving. For example, it might limit the total number of segments the device sends for a single file or outright disconnect the device if it sends them in some weird order.
 
 Moreover, the broker does not require the device to complete the transfer in a single session. The device can disconnect at any time and then reconnect and continue the transfer from the point where it left off. Or even restart it from the beginning. For that to work, the broker requires the device to assign a unique *file id* to each transfer. The device must send this identifier in each command and should not reuse it for different transfers.