[LibP2P] Distinguish between slice peers vs full node peers when requesting

[Djadih]

mechanikalk — Today at 2:32 PM
If something is broadcast when it is created it will propagate with libp2p. That being said, if we get a request for a headerview we need to be able to fulfill it regardless of processing state.
DJ_ADI — Today at 2:39 PM
There shouldn't be a mismatch between the data a node is serving and what people ask of it. For example slice nodes don't subscribe to the blocks topic of slices they aren't running, so they shouldn't end up in those peerdbs and won't be requested for that data
mechanikalk — Today at 2:49 PM
But a full node will be interested in headers and serving headers
DJ_ADI — Today at 2:50 PM
Yes a full node subscribes to both headers and blocks, and publishes to both. A slice subscribes only to headers
But actually there is a potential wrinkle, which might explain the response timeouts in slice tests. The peerdb doesn't distinguish between data types. Peers who serve just headers are in the same db as those who serve both headers and blocks
mechanikalk — Today at 2:52 PM
They are different dbs
Oh peer db
Yes we need to change that

[Djadih]

For slices:

• Persistent connection with header providers
• Slices need peers distributed across the network. eg 10 peers per context
• 10 block producers for my context

For full node:

• 10 block producers per context
• 10 header providing peers for every context

[Djadih]

1. Slices provide their CID in the DHT
2. Swap out location for full topic cid in peerdb
3. Filter by cid when requesting peers