IPFS for M2M and IoT

Ecosystem
1

Hi

I’ve been working with ipfs for some time and I think it has great potential in the field of IoT. What I am currently testing is to integrate it into an ecosystem of IoT. In the past I tested orbitdb performance on a 256MB RAM orange pi zero (published in this paper) with the js-ipfs implementation as soon as the memory limit was reached it got stuck, but the go-ipfs implementation works perfectly.

So the point is now to test the communication within an ipfs network. I’ve deployed a private ipfs network and I’m developing a kind of decentralized broker that basically manages the communication process between nodes (gitlab project).

The persistence of the messages is implemented with orbitdb, each topic is considered as a db, to make it more efficient I should consider through the event handler to close the db after replicating it with another peer to avoid have a bunch of nodes with open db (with one would be enough).

But depending on the use case it may not compensate to have persistence, so a simple messaging protocol between nodes would be a better option, for that case it would be enough just using the ipfs pubsub option.

I have done some tests with a pair of orange pi and 4 docker nodes connected to the local network, my first impression is that pubsub has no QoS level, sending 100 messages in parallel to a topic with a nodejs script and received almost instantly 63 in the subscriber but nothing more. Anyway it could be implemented with the own pubsub library doing some kind of guarantee of reception by sending ack messages to the topic by the subscriber and with a timeout for redirection.

What is the current state of the pubsub library? In a blog thread the following was commented. “The current routing algorithm floods messages to every subscriber”. This could be a problem but it depends mostly on the use case too, At the moment with a network of 5 nodes 4 of them sending every second to a topic I didn’t see that behavior, but I will make a bigger network to push the limits :slight_smile: and test the scalability.

If anyone else finds all these things interesting, comment that my final idea is to use all this in a blockchain, I don’t sure yet which but IOTA seems to fit very well, (besides the base is a merkle-dag like IPFS) So the point with this is (among other things) to have a decentralized backend to process the stored information on IPFS, since the trend is to make increasingly powerful and low-power IoT devices, it would be interesting to delegate tasks of processing to them and thus eliminate the need to use an cloud or fog server for this purpose. Obviously not in the nodes that are sleeping most of the time and send data periodically, but there will be nodes that are permanently powered that could do this task.

2

This refers to the “FloodSub” strategy.
Just so you know: JS now uses GossipSub. Go uses GossipSub since 0.4.18 and you can have insight here.

3

Thanks for the reply, I see in this link some interesting features for the pubsub library I’ll test it later.

4

Hello

I’ve made some progress for this topic, recently I’ve tried this orbit go implementation in several RPi / OPi and I’ve learned a little bit of the basics of golang, orbitdb in go on a Pi offers a good performance (better than the original js implementation) so the persistence part is already more or less defined. However, for the messaging protocol the gossipsub strategy could be quite efficient but I need some more options to get closer to a M2M protocol, I had thought to develop at least the 3 QoS levels and the retained message option offered by MQTT, my idea is that a Pi works as an edge computing device and the sensors that will be in deep sleep send measurements periodically to the Pi by Ble, WiFi or other wireless protocol with a distributed storage of the measurements in orbit. I suppose that the most suitable would be to add it as experimental options of go-ipfs (the last link in the Akita reply) that will run over pubsub, some as IPNS pubsub already could use them to make discovery of topics, that would be an interesting add-on.

I wanted to know if this approach seems right or if I should approach it differently, I saw several videos and evaluations of the gossipsub algorithm and seems pretty scalable and much more efficient in terms of network consumption than the initial one of ipfs, the idea is not to make a protocol as efficient as MQTT the idea is to use a distributed one that does not depend on a cloud or other centralized service.