# Problems with gossipsub **URL:** \ **Category:** Help\ **Tags:** go-ipfs\ **Created:** [January 28, 2019, 1:16pm UTC](https://discuss.ipfs.tech/t/problems-with-gossipsub/4764 "2019-01-28T13:16:35Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![rklaehn](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/rklaehn/32/244_2.png) [@rklaehn](https://discuss.ipfs.tech/u/rklaehn)\ **Post date:** [January 28, 2019, 1:16pm UTC](https://discuss.ipfs.tech/t/problems-with-gossipsub/4764/1 "2019-01-28T13:16:35Z")
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… ---
**Author:** ![chris](https://avatars.discourse-cdn.com/v4/letter/c/958977/32.png) [@chris](https://discuss.ipfs.tech/u/chris)\ **Post date:** [January 30, 2019, 12:46am UTC](https://discuss.ipfs.tech/t/problems-with-gossipsub/4764/2 "2019-01-30T00:46:22Z")
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. ![](https://us1.discourse-cdn.com/flex020/uploads/ipfs1/original/2X/1/14a6d1644fe4c21e80c66ea4b7c9a961e45dc1c6.jpg) 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. ---
**Author:** ![rklaehn](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/rklaehn/32/244_2.png) [@rklaehn](https://discuss.ipfs.tech/u/rklaehn)\ **Post date:** [January 30, 2019, 2:47pm UTC](https://discuss.ipfs.tech/t/problems-with-gossipsub/4764/3 "2019-01-30T14:47:02Z")
> [@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. 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…