Support MQTTv5

[voycey]

Feature Request

MQTT 3.1.1 is an ancient protocol (2014), that has been superseded for many years now by MQTTv5 (2018), it comes with a whole heap of important feature for IoT that were overlooked in the MQTT 3.1.1 spec. NATS is a great MQ and could be a one stop shop if it supported the latest protocol version, the plugin ecosystem of NATS would fit in perfectly with this and create an ecosystem that is currently dominated by overpriced cloud hosted solutions.

For example - to currently take MQTT data and drop it into object storage requires several different services cobbled together, NATS could handle this with 1.

Use Case:

There are so many important new features in MQTTv5 including:

• Hugely streamlined protocol for massive deployments
• Enhanced Authentication Methods
• Session Expiration
• Payload format indicator and content types
• Response Topics
• Shared Subscriptions
• Improved Message filtering
• ACK reason codes
• Improved Last will and testament
• User Properties (The biggest one IMO)

User Properties allow for arbitrary data to be attached to the MQTT message, this opens up a huge set of functionality for IoT networks that MQTT simply didn't cater for in the past (or required things like Topic structure to be fudged to handle the same).
This allows for Dynamic data to be encoded as part of the MQTT message itself.

Proposed Change:

Perhaps look at implementing the Paho MQTTv5 library rather than rolling your own? https://github.com/eclipse/paho.golang, this would cut down on development time significantly

Who Benefits From The Change(s)?

I believe that MQTT 3.1.1. is only kept going because of the refusal of service providers to implement MQTT v5 but it is also contributing to the low pick up of services offering this (look at Google IoT Core - it has just announced shutting down, I believe for this very reason).

The whole IoT community will benefit from having a premier project such as NATS implement MQTTv5

[derekcollison]

Would you be willing to submit a PR or fund this work?

[voycey]

Is it feasible to use the Paho library for this? Funding is possible but ill have to discuss it as part of the project plan which is likely 6+ months before we will move away from the current solution!

[derekcollison]

I will take a look, won't happen in the 2.9 release which we have been prepping for some time, but possibly thereafter along with QoS2.

Keep us posted, and thanks for the feedback and request.

[cbrake]

https://github.com/eclipse/paho.golang mentions it is a client library. Would this also be useful to implement the MQTT server side functionality?

[derekcollison]

Possibly. We are very selective at external dependencies for the server, but worth a look.

[leandrofars]

Hi, there were advances in the implementation of MQTTv5 ? We're looking to use NATS as a broker for our project, since we already have a hole ecosystem running in NATS. But our project that uses MQTT must follow TR-369 protocol, and the protocol says we must implement MQTTv5. TR-369 protocol documentation

[derekcollison]

Its still on our list but we have other higher priority items at the moment.

But if you would be willing to sponsor the work let us know.

[sandrokeil]

Any plans to work on this in the near future? Supporting MQTT v3.1.1 and MQTT v5 could be a game changer for NATS.

[derekcollison]

No customers asking for v5 yet. We are doing some work on MQTT for release 2.10 however.

[voycey]

I think I have mentioned this in a few different places, I don't think Customers will necessarily ask for it but it would be a "Build it and they will come".

There are almost zero composable solutions on the market that can handle MQTTv5 properly, almost everyone I know who is using it has had to cobble together a solution from Mosquitto and Paho / mqtt.js and that is a 1 way street, once that is built they are highly unlikely to move away from that.

The choices are to either use a full stack broker and build the tooling yourself or to handle it a different way altogether. If there is a solution that will properly support it - then why would anyone go out and build it themselves?

Since posting this AWS IoT is now supporting MQTTv5 and honestly this is probably the best way for people to get started right now, however if you want to move items outside of this ecosystem in an event driven way then its not currently feasible without some message queue that understands it.

Influx & Telegraf have just started supporting it but only a small subset - not a full end to end solution but it would likely be where people end up right now.

[onedr0p]

There are almost zero composable solutions on the market that can handle MQTTv5 properly [...]

I've used vernemq and emqx in the past, they seem to work fine for my use cases when I needed it. I would still love to see nats support MQTTv5 though.

[matthewadams]

We'd like to reduce the number of moving parts in our system, one part of which would be to move away from vernemq to nats, since we're already using nats. MQTTv5 is required for us, though, because we necessarily make use of shared subscriptions and custom authentication & authorization.