Method to do pubsub over local network only

[RangerMauve]

Hello, I was talking to folks at the IPFS Thing last week about how I have a use case where I'd like to keep gossip to a particular network interface or to limit it to a local network.

The general use case is for local network service discovery / gossip which lets you find folks advertising data on your wifi hotspot/router rather than globally gossiping about a topic. For this use case the application would have a hardcoded "service discovery" topic so that peers wouldn't need an extra layer of data exchange to establish gossip.

I was wondering if this is something that could be done with the existing libp2p pubsub implementations or if it's something we could spec out as a standard.

I have some thoughts on how it could be done, but I wanted to do a temperature check on whether it's something we could spec out before writing too much about it.

[mxinden]

:wave: @RangerMauve,

I was wondering if this is something that could be done with the existing libp2p pubsub implementations

I am not 100% sure I understand the use-case. What technical blockers do you foresee? Would you not just need to (a) listen on a specific interface and (b) make sure you only connect to nodes within your local network?

or if it's something we could spec out as a standard.

Can you extend on what is missing / blocking in the current specification for this use-case?

[RangerMauve]

am not 100% sure I understand the use-case. What technical blockers do you foresee? Would you not just need to (a) listen on a specific interface and (b) make sure you only connect to nodes within your local network?

It'd be possible to do this using ad-hoc code (I think), but what I wanted to get at with this issue was to find a path to standardizing this functionality within libp2p pubsub implementations in general.

Can you extend on what is missing / blocking in the current specification for this use-case?

Looking over the spec, I'm actually not sure if this is the right place to bring this functionality up or whether I should open new ones on the specific libp2p implementations.

Ideally it'd be nice to specify which discovery mechanism should be used for peers. e.g. telling pubsub to only use mdns for discovery and skipping the DHT.

[mxinden]

Ideally it'd be nice to specify which discovery mechanism should be used for peers. e.g. telling pubsub to only use mdns for discovery and skipping the DHT.

I can only comment for rust-libp2p. In rust-libp2p GossipSub or Floodsub are not aware of the concept of a discovery mechanism. They work with whatever connections you give it. Thus it is up to you to control which nodes to connect to, e.g. via the mdns discovery mechanism or the Kademlia discovery mechanism.

[RangerMauve]

Interesting. It sounds like this might be something I should raise in specific libp2p implementations to see if they could add an option?

Ideally I wouldn't want to have to create a separate libp2p swarm just to limit pubsub to use mdns. 😅

[MarcoPolo]

I'm not very familiar with the go-libp2p pubsub implementation, but my guess is that you can probably do something where you manage the peers the pubsub system knows about manually. Then you can filter the peers to only peers on your local network. I think you can do something similar in rust-libp2p.

It's a bit of work, but much easier than making a global spec change and cross implementation change. Also it would allow us to play around with this before committing it to the first-class api.