Context
ProbeLab completed a GossipSub setup and configuration review of the Filecoin network: https://www.notion.so/probelab/M3-GossipSub-setup-and-configuration-review-32deaf461d4780439f15c3c4c7d7655c. In the 2026-05-12 Filecoin implementer sync, we agreed to create this top-level tracking issue for coordination. Each implementation team should create its own sub-area tracking issues in the relevant repo(s), then link them here.
The goal is to make sure each finding is reviewed by each affected implementation, while keeping cross-implementation coordination visible in one place.
Sub-area tracking matrix
1.1 PeerExchange only enabled for bootnodes
TL;DR: PeerExchange is currently only enabled for bootnodes, which limits GossipSub-based peer discovery. We should evaluate whether each implementation should enable PeerExchange more broadly, while ensuring only appropriate public/reachable peer information is shared.
1.2 PeerExchange not fully supported in rust-libp2p
TL;DR: Forest cannot fully benefit from GossipSub PeerExchange today because rust-libp2p lacks complete SignedPeerRecord support. We need to track what is required upstream and whether Forest needs interim handling.
2.1 Global flood publishing
TL;DR: Flood publishing is enabled globally in the Go GossipSub configuration, which may significantly increase publisher-side bandwidth, especially with F3 traffic. We should validate the bandwidth and propagation impact, then decide whether to keep, disable, limit, or make this behavior topic-specific.
2.2 Peer ID exposure / WithNoAuthor
TL;DR: Messages currently include the originating peer ID, which may make SP/network identity correlation easier. We should evaluate the privacy benefit of enabling WithNoAuthor against the loss of observability and network-health metrics.
3.1 GossipSub validation queue size
TL;DR: The validation queue size may be too small during F3 or high-throughput message spikes, which can cause dropped messages and consensus delays. We should review defaults, monitor rejection metrics, and consider increasing the default, e.g. to 512, where appropriate.
Context
ProbeLab completed a GossipSub setup and configuration review of the Filecoin network: https://www.notion.so/probelab/M3-GossipSub-setup-and-configuration-review-32deaf461d4780439f15c3c4c7d7655c. In the 2026-05-12 Filecoin implementer sync, we agreed to create this top-level tracking issue for coordination. Each implementation team should create its own sub-area tracking issues in the relevant repo(s), then link them here.
The goal is to make sure each finding is reviewed by each affected implementation, while keeping cross-implementation coordination visible in one place.
Sub-area tracking matrix
1.1 PeerExchange only enabled for bootnodes
TL;DR: PeerExchange is currently only enabled for bootnodes, which limits GossipSub-based peer discovery. We should evaluate whether each implementation should enable PeerExchange more broadly, while ensuring only appropriate public/reachable peer information is shared.
1.2 PeerExchange not fully supported in rust-libp2p
TL;DR: Forest cannot fully benefit from GossipSub PeerExchange today because rust-libp2p lacks complete
SignedPeerRecordsupport. We need to track what is required upstream and whether Forest needs interim handling.2.1 Global flood publishing
TL;DR: Flood publishing is enabled globally in the Go GossipSub configuration, which may significantly increase publisher-side bandwidth, especially with F3 traffic. We should validate the bandwidth and propagation impact, then decide whether to keep, disable, limit, or make this behavior topic-specific.
2.2 Peer ID exposure /
WithNoAuthorTL;DR: Messages currently include the originating peer ID, which may make SP/network identity correlation easier. We should evaluate the privacy benefit of enabling
WithNoAuthoragainst the loss of observability and network-health metrics.3.1 GossipSub validation queue size
TL;DR: The validation queue size may be too small during F3 or high-throughput message spikes, which can cause dropped messages and consensus delays. We should review defaults, monitor rejection metrics, and consider increasing the default, e.g. to 512, where appropriate.