Question borrowed from StackOverflow. I’m posting it here, so hopefully it’s seen by more people.
Is there a way to do IPFS pubsub message forwarding if the intermediate node does not subscribe to the topic?
A <-> B <-> C
As above, there are configurations where A and C are not directly connected but A and B or B and C are connected. ＊A, B and C are IPFS Peers.
If C subscribes to a Topic and A publishes a message, C cannot receive the message unless B subscribes. ＊Tested with Kubo v0.15.0.
Is there a way for C to receive message even if B has not subscribed? If so, please let me know.
If C subscribes to a Topic and A publishes a message, C cannot receive the message unless B subscribes. ＊Tested with Kubo v0.15.0.
I have the same issue, but after I’ve read this doc, I think pubsub can’t be forwarded through peers that aren’t subscribed to topics.
As described in the documentation, the message broadcast of pub/sub must be between peers that have subscribed to the topic.
When peers subscribe and unsubscribe, they will broadcast subscription lists to other peers, and when peers connect to each other, they will also exchange subscription lists.
When peers publish a message, it is published only to peers that have subscribed to the topic.
This design makes pubsub more secure and reliable, does not spread messages among extraneous peers, and avoids large-scale network data flow.
Of course, this will cause problems with peers subscriptions after NAT, especially when both peers are behind NAT and do not successfully Hole Punching, pub/sub communication cannot be carried out through the connected public peer.
1 Like
As you can see from this image, all metadata-noly and full-message peers must be in the same topic. Therefore, all data about metadata-noly and full-message in the documentation is delivered under the premise of subscribing to the same topic.
Discovery
Before a peer can subscribe to a topic it must find other peers and establish network connections with them. The pub/sub system doesn’t have any way to discover peers by itself. Instead, it relies upon the application to find new peers on its behalf, a process called ambient peer discovery.
Potential methods for discovering peers include:
- Distributed hash tables
- Local network broadcasts
- Exchanging peer lists with existing peers
- Centralized trackers or rendezvous points
- Lists of bootstrap peers
For example, in a BitTorrent application, most of the above methods would already be used in the process of downloading files. By reusing peers found while the BitTorrent application goes about its regular business, the application could build up a robust pub/sub network too.
Discovered peers are asked if they support the pub/sub protocol, and if so, are added to the pub/sub network.
So, if your peer B not subscribed THE TOPIC , it can not to forward message from A to C.
1 Like
Thank you so much for your detailed response, it makes perfect sense! I’ll pass that on to StackOverflow when I get a moment 
.
