Problems with gossipsub

[rklaehn]

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...

[chris]

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.

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.

[rklaehn]

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.

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....