celestiaorg
modp2p: analyze the default ip colocation threshold for gossipsub
Current value of 10 might be overrestrictive. The hypothesis is that it harms gossiping to LAN networks with more than 10 peers by silently ignoring those who do not fit into the limit.
The counter argument here is that the limit is per server, so if there are 10 serving BNs in total then the LAN network of 100 peers should be sufficiently covered, as it stands with at least GO implementation of gossipsub protocol.
Additional point worth noting is that libp2p rust may support browser to browser connections(in case if lumina is a client) as well discovery, s.t. gossiping could continue with a LAN, even if some of its peers are not linked in gossipsub mesh.
libp2p rust may support browser to browser connections
this may be achievable with some non browser relay node and hole punching, but that's definitely not a case now
I need to read more about how the actual limit works in go libp2p. Just throwing my 2 cents for now. I think even if the limit is quite reasonable for regular cases, there are at least 2 things that make this case much worse for lumina:
- lumina doesn't persist peer id, so each time you start it, it appears as a new node. This contributes to black listing a lot I believe, each time you refresh a tab, you are treated as another node from the same IP. If someone is developing with lumina, and say he has 2 tabs open, he has only 5 refreshes until limit is hit.
- There's currently a webtransport throttling issue in chrome based browsers which basically doesn't allow opening new connections after some limit. This effectively cuts lumina peers discovery at ~15 peers and only allows new connections after long time period. This doesn't allow lumina to have a healthy placement in a mesh and most of the lumina nodes will be connected to the common peers (bootstrappers)
For Safari the things are even worse as the only working transport there is wss, which cannot be expected to be set up by regular peers, so from Safari we assume the only peers lumina have is bootstrappers
@zvolin, the first issue you mentioned is something that has to be fixed asap. Not only for the reason you mentioned, but also because it skews our monitoring of number of peers.
Just posted a comment regarding persistent peer ID: https://github.com/eigerco/lumina/issues/116#issuecomment-2943636978 Any comments/ideas are welcome.
