IPFS pubsub: Optional integrated pubsub MQTT broker

kallisti5 commented 2 years ago

Checklist

[X] My issue is specific & actionable.
[X] I am not suggesting a protocol enhancement.
[X] I have searched on the issue tracker for my issue.

Description

MQTT is the universal standard for pubsub messages supported by a wide range of applications and devices. It would be nice (tm) if the IPFS daemon had an optional MQTT broker built-in to accept native MQTT pubsub messages into the IPFS pubsub ecosystem (generally via TCP port 1883)

Multiple go libraries exist which would reduce the code and maintenance requirements. https://emqx.medium.com/how-to-use-mqtt-in-golang-87dab475ea92

Example use cases

IOT-enabled devices like OpenEVSE, Solar grid-tie inverters, and pretty much anything that supports pubsub via MQTT
Last-mile IOT bridge networks like LoraWAN operate on MQTT messaging

Jorropo commented 2 years ago

I'm not sure of the value adding this feature to go-ipfs.

Wouldn't this make sense as a separate binary (either running a separated libp2p node or using the pubsub api) ?

kallisti5 commented 2 years ago

That's a good point, however 99.9% of the pubsub world operates via mqtt which IPFS doesn't offer. I'd argue that dropping the native ipfs pubsub api for mqtt would make it more widely used.

Arlodotexe commented 2 years ago

MQTT support makes a lot of sense, actually, as it's the defacto standard for IoT devices.

At the very least, a compatibility layer would be super useful. It looks like someone has already created notes on this and made a very rough prototype here: https://blog.cryptostars.is/a-decentralized-mqtt-broker-for-iot-on-web-3-0-1b45ce191f44

BigLep commented 2 years ago

We're closing this because this is extra functionality that we don't believe should be exposed on top of go-ipfs/Kubo.

Our suggestion is to create a separate binary/application on top of libp2p or drive a spec conversation in libp2p/specs.

ipfs / kubo