Messages are not propagated when only some nodes subscribe a topic

[vasco-santos]

Let's consider a simple network with 3 peers {A, B, C}, with 2 connections established A<->B and B<->C

In this scenario, if A subscribes to a given topic and C publishes messages to that topic, A should be able to receive the messages.

It seems to me that https://github.com/ChainSafe/js-libp2p-gossipsub/blob/v0.8.0/ts/index.ts#L1034 this should not break here, otherwise we will not grab fanout peers. However, this does not seem to fix the issue, as I tried to do a small hacking in the code but messages were not sent to the peer.

Other than that, should we make canRelayMessage options to be true by default? I would expect the default behaviour to relay messages, but users might turn that off if they like.

Test scenario to test: libp2p/js-libp2p-interfaces#83 (use this branch as a dep)

@wemeetagain any ideas on what is wrong here?

cc @Gozala

[wemeetagain]

I'm curious how this scenario works using go-libp2p.

It seems C won't send the message to B because nodes only send messages to peers which have subscribed to the topic (or direct peers).

As far as I know, publishing a message follows something like this:

• publish to all direct peers
• if flood-publishing is enabled
  • publish to all peers subscribed to the topic
• else
  • publish to floodsub peers subscribed to the topic
  • if we are in the mesh for the topic
    • publish to mesh peers (peers subscribed to the topic)
  • else
    • publish to fanout peers (possibly creating fanout peers from peers subscribed to the topic)

[vasco-santos]

@wemeetagain I also noticed that, both in go code and spec. This is strange though, while I understand that the real world scenarios are bigger topologies, I would expect this to work. What do you think?

I did a small test with go daemon and it has the same behaviour and the other peer does not receive messages https://github.com/libp2p/interop/blob/chore/try-3-go-gossipsub-with-hop/test/pubsub/gossipsub/go2go2go.js

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue or pull request has been automatically been closed due to inactivity.

[3xtr4t3rr3str14l]

is this still an issue?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.