Roadmap ?

Hello,
I hope you're doing well. I’ve been exploring this repo. I was wondering if you’re planning to continue maintaining it? Additionally, I’m curious if you’re considering adding any new features or updates. Are you aiming to eventually release a 1.0 version?
Thanks!

Deno is yet to have a mature mqtt library thats why asking.

Hi,

thanks for asking!

Its a hobby project to me which I started with two goals in mind:

get to learn Typescript
get to learn Deno

I'm not using it in any production like capacity.

My plan (if I find the time) is to port it to Node.js so it will run on Node, Deno and Bun and maybe some others as well, as everybody has Node compatability these days. The only hard depency on Deno currently is in the Deno socket all other stuff is plain vanilla Typescript/Javascript.

Feel free to submit ideas or PR's, fork it or borrow ideas.

Kind regards,
Hans

Btw: although not part of the standard library it is on JSR.io ;-)

Current version is 1.0.18 and it has been tested against https://github.com/eclipse/iottestware
(see https://github.com/seriousme/opifex/blob/main/bin/conformanceServer.ts)

The implementation has been hardened against potential adversarial messages (e.g. oversized, undersized, malformed etc) and protocol misbehaviour E.g. it looks for message size then reads the whole message before attempting to parse it.
Message size is capped at 2Mb and can easily be adjusted, see:

opifex/mqttConn/mqttConn.ts

Line 86 in e742c86

this.maxPacketSize = maxPacketSize || 2 * 1024 * 1024;

Hope this gives some insight into the robustness ;-)

Kind regards,
Hans

Current version (1.3.0) runs on both Nodejs and Deno, Bun is having some issues with the socket stream.

@seriousme Are there any plans to allow the server to have handlers that can read and do stuff with messages such as onPublish etc? I'm interested in using this in an IoT project and would need to be able to read the message contents. If you don't plan to add it but wouldn't mind having it as a feature, I could contribute the code.

Hi,

I don't have any specific plans in this direction. Can you elaborate a bit more on what you want to achieve?

E.g. if you want to add persistent storage you can already use the persistence interface (https://github.com/seriousme/opifex/blob/main/persistence/persistence.ts) to create your own storage adapter.

And if you want to use custom authentication/authorization you can supply your own handlers.

Kind regards,
Hans

Hi! Thanks for the prompt response :) I just need to be able to access the published events in my server code, since I run a kind of HTTP-MQTT gateway. As a workaround I decided to use a loopback MqttClient that just connects to localhost, but I'm having another issue - the server just seems to reject all connections. When I do console.log(conn) in my for await loop, it prints TcpConn {} but my testing MQTT client (mqttui) just reports constant "Connection refused" (I think it's ECONNREFUSED). I'm not sure if it's because I'm also running an HTTP server in the same application - do you have any ideas what could be going wrong?

Edit: okay, I was just invoking the command incorrectly! Sorry to bother you. Thanks for your work on this lovely library.

Hi, best solution for a HTTP-> MQTT gateway is to have the HTTP server use an MQTT client, that way you don't need to fiddle with the MQTT server and you can always use any generic MQTT server.

Kind regards,
Hans

@seriousme - the issue is that I want to be able to pass on certain events but not others (i.e. if the event contains invalid/malformed data). Also I want to be able to ratelimit by IP.

Opifex is very strict in parsing MQTT packets and will immediatly drop a session if a malformed MQTT packet is received. So you will only see correct MQTT packets at MTTQconn level.

Application level message validation is typically not a task of the MQTT server, as the application message format lives at application level and not at MQTT level. The application subscribing to the topic and acting on the contents of the message would typically validate application level message formats and drop illegal application level requests.

Rate limiting clients is typically also not too much of a problem as you'd typically only allow authenticated clients.
However you could still have abusive clients trying to overwhelm the authentication mechanism.
These are typically handled at netwerk level (e.g. firewall or network Access Control List) but you could also implement it as part of the TCPserver implementation.
Another way to solve it is to look at the ctx parameter of isAuthenticated , this contains an conn object which is a SockConn from which you can find the client IP.

This same ctx parameter is also present in isAuthorizedToPublish and in isAuthorizedToSubscribe.

Hope this helps.

Kind regards,
Hans