ProtoMQ: Type-safe, bandwidth-efficient MQTT.

Download the new release and comment on your thoughts!

https://github.com/electricalgorithm/protomq/releases/tag/0.2.0

(You'll love the updates! Don't go away, scroll down and read the next paragraph.)

---

The project got quite an interest on GitHub repository. I don't know if people are using it in their projects, but the stargazer count increased to 23. Compared to other projects I had, it's a quite fast increase in one-month.

What has changed?
This version ships a service discovery feature where clients can ask MQTT what data formats are available for which topic. This feature is a replica of gRPC's service discovery, with a bit translated to a "data format" mentality rather than procedure calls. Furthermore, a new admin server (HTTP server) is designed to add new protobufs to the broker and map them to topics. The server's HTTP API is protected with an auth token and only works on loopback currently to reduce the security risks.

These two features enable my dream of having "no updates" to clients when I want to change my data packet format. They even allow me to build a decoupled system like HomeAssistant, where one end only knows what data formats they can share, and the other end only knows what data formats they can consume.

A Docker file is also added to easily run the server without having Zig download hassle.

What's planned?
I'll continue to develop the project by introducing QoS 1 and 2, possibly MQTT-over-TLS support. I shared the project with several boards to gather feedback from people. Would love to see yours to plan a future roadmap.

Thanks!

One of the biggest pain points in using Protobuf with MQTT is the rigidity of the message types. In a standard setup, if you want to change a schema, you often have to rebuild and restart the broker. Not with ProtoMQ.

We've just implemented an optional HTTP Admin Server that brings operational visibility and hot-schema updates to the broker without touching the "hot-path" of message routing.

What’s New?

• Dynamic Schema Registry: You can now register .proto files at runtime via POST /api/v1/schemas. This allows the broker to start decoding new message types instantly without a restart.
• Live Telemetry: A new /metrics endpoint provides JSON-based visibility into active client connections and total messages routed.
• Zero-Overhead footprint: True to the project's goal of running on the smallest embedded targets, this server is strictly conditional. By using Zig's build system (-Dadmin_server=true), you can choose to include it for development or larger controllers, while stripping it entirely for tiny edge devices.
• Shared Event Loop: To ensure zero jitter in MQTT delivery, the Admin Server runs on the same non-blocking IOContext event loop as the broker. No threading overhead, just cooperative multitasking.

Why this matters for IoT?

Debugging a distributed fleet of sensors is hard enough. By adding standard HTTP-based monitoring and schema management, we've made ProtoMQ ready for production environments where "set and forget" isn't an option, all while maintaining our sub-millisecond latency targets.