Problems with gossipsub

Coding
#1

Hi,

I was eagerly awaiting the new gossipsub, so I was quite happy that it arrived in 0.4.18. Today I finally got the chance to play with it a bit. I got a private network with a topology where there is a central node B and nodes A and C are connected to it, but not to each other. So like this

A <-> B <-> C

Now when I publish on a topic test on A and listen to that same topic on C, I had expected gossipsub to discover that the two nodes are sharing a topic and to make sure that the messages flow. But from what I see, this is not the case. I still have to subscribe to the test topic on B for the messages to get through…

Is this a bug, or did I just misunderstand what gossipsub provides?

Implementing gossipsub was a major effort, so what’s the plan to make it a non-experimental feature? It would be really bad to spend a lot of effort on it and then move on and leave it in an experimental state. There are way too many experimental features as is…

#2

From a performance and scalability point of view it makes sense for only having nodes subscribed in a topic participate in message propagation and for nodes that are not subscribed to not participate, even as a relay.

From a stability point of view it does create situations where connections to topics are not established.

One thing that I am unsure about is if you can end up “islanding” your node with other nodes where connected nodes no longer have a link to the provider of the topic.

Untitled Diagram(2).jpg832×1122 106 KB

From the islanded nodes perspective they …
a. Are connected to multiple peers subscribed to the topic.
b. Have valid messages from the topic. (unknowingly outdated)
c. Have a strong connection with the ipfs swarm.

There are methods that might be able to mitigate this (like heartbeat messages or TTLs) but I am unsure if any are actually in place or not.

#3

It makes sense that a node should not by default become a relay for a topic that it itself is not interested in (although that would be a good option to add, maybe in the context of circuit relay).

But in the case above all nodes A, B and C can reach each other (no double NAT or anything else nasty). So I would expect that if A and B are interested in the same topic they would become peers, and I did not see that.

If I have to explicitly make sure that the nodes that are interested in a topic are all directly or indirectly connected, it’s not much of a pubsub system, is it? The whole point of a pubsub system is that you don’t have to connect to individual nodes…