I’m working on a little IPFS project where all nodes need to know of each other if they are online. This is without maintaining node lists.
My initial thought was a kind of chatroom application. But upon further experimenting with pubsub it seems like there is no pubsub default of broadcasting your presence, is that correct?
I cannot use
ipfs pubsub peers(topic) as you get no signal or whatsoever to know that a new peer is subscribed to a topic. If you were to use this, you were to be polling it to detect changes. Not ideal.
I come from some socket.io experiments from years ago where you joining a “room” was a new connection that you needed to handle and thus knew someone joined hence i was assuming the same to be true here. But IPFS doesn’t emit any signals (as far as i know) when one joins a topic (subscribes). It should be possible to add that to the protocol as a new peer for a topic is added to
ipfs pubsub peers just no notification of it exists. It’s not a big issue at all, just sending a publish message with some identifiable payload does the trick in this case.
What’s with the topicIDs array?
So each message that flows in has a topicIDs array. What’s the rationale in having that?
The message is already send to a specific topic from the sending side and the receiving side is already subscribed to a specific topic. I’m sure there is a really good reasoning, i just don’t see it yet Should i use this array? Just curious to know about this one.
How should large payloads be send?
By large i mean, at most, multi megabytes. But i wonder if a logic of always having a CID as payload and using plain IPFS to get the data is the way to go be default? The payload would then always be as large the CID is in characters. The cost here would be added delays due to getting content from IPFS. The alternative would be to just use pubsub for the data. Any recommendation here on what is still sane for pubsub in terms of payload size?
Potential spam flooding
So this is a bigger issue. As far as i know anyone can send anything to any topic. How is an app using this mechanism supposed to filter out the spam? To give an example of how a case where it could be abused. Imagine if there is a service (could be a chat site even!) out there using pubsub for it’s main operation. Now imagine there to be a “mad person wanting to take that site down”… All that person has to do now is write a dead simple bash script with a loop to completely flood a given topic. The receiving side will have to handle every message to determine if it is a proper message for it’s service (disgard if not, use if it is). That handling when flooded with millions of messages will likely kill a service. I haven’t tried this but i assume it would work.
That begs the question: how can we use pubsub and somewhat safely assume a topic won’t be the victim of a bad actor?
I’ve been trying to think of a way to prevent flood protection. Like actually blocking bad actors. But i can’t think of any mechanism (yet) that would allow detection and keep the API as simple and clean as it is now. All i can come up with is methods of “registering” a topic and defining rules for posting in that topic. But that smiles like one node being the “master” which imho kinda defeats the point of being decentralized. Unless you could define the rules for a topic in a public way, like storing the rules on IPNS. If everyone can still see the rules, but only some can obey them… That could work. That would require multiple API changes though.