ESP32 Support (or just no_std in general)

[sebadob]

Proposed change

Recently, Rust on ESP32 and embedded devices in general has made huge steps forward. By now, we can even execute std Rust and fully async runtimes like tokio on just an ESP32 device.

I don't know, if this would even be possible without huge changes internally, but would it somehow be possible to introduce a new feature flag, which would reduce the dependencies as much as possible and, more important, get rid of any dependencies that pull in ring ? There are wrappers and all sorts of things, that make it possible to just use TLS directly on these devices already with HTTP or WS connections. If possible, it would be a huge advantage I guess, if async_nats could use something like https://esp-rs.github.io/esp-idf-svc/esp_idf_svc/tls/struct.EspTls.html instead of bringing its own TLS suite, which pulls in ring.

The existing libraries have all sorts of functionalities built-it and you can use mqtt right away without needing to add anything else, but it would be so much more convenient if we could use Nats directly without configuring the mqtt bridge.

Use case

Make it possible to build all kinds of embedded / IoT devices from microcontrollers with direct NATS support instead of bridging between MQTT and NATS.

Contribution

I have never worked with the internals of this crate so far, but I could give it a shot. It would actually depend on the answer from someone who knows the code, if it makes sense as a "good first issue".

Edit:

... or maybe an integration with https://github.com/drogue-iot/embedded-tls can be done.
I think at this point, the only missing part to make it work in embedded systems is TLS.

[Jarema]

Hey!

That is an interesting opportunity to pursue.
The embedded-tls crate looks interesting and it does seem to support async API, but it's also narked as a work in progress, which sounds scary for such sensitive thing as TLS.
On the other hand the EspTls seem to by sync only, though I might be wrong here, as I just did a quick check.

Feel free to experiment on a fork and let us know. The TLS code is referred in very few places in the codebase, so despite this issue sounding like a low level stuff, it might be pretty easy to pick it up.

However, keep in mind that we have to be careful when enabling/disabling TLS related features and dependencies, so no promises that it would be merged.

[paolobarbolini]

What do we think about using rustls with the third-party mbedtls crypto backend?
https://github.com/fortanix/rustls-mbedtls-provider

[Jarema]

I looked at it briefly and it looks like a promising option @paolobarbolini

[sebadob]

I had a few more thoughts about this.
WebSocket is almost always available on embedded no_std devices, natively.
We can run Nats with WebSocket enabled.

Would it be possible to make async_nats work over WebSocket with a feature flag? Maybe with only basic support without stream configuration, since you would usually do this from a bigger server anyway instead of from IoT devices.
Maybe we could use the already existing logic and structs from inside native embedded on message handlers.
This would mean someone would need to do a bit more manual work to set it up, but maybe also make it possible to use the crate in environments like WASM and so on?

[Jarema]

Websockets are planned.
Should be possible by swapping the transport as other clients do that.