As stated by @amesgen:

In preparation for more optimized versions of the vote diffusion logic, ie where we don't download all votes from all peers, which we would do if we would simply use our existing generic object diffusion implementation for votes (which makes sense in the very beginning), we could look at prior art in this area.
More specifically, we want to find a good balance between:

• Network efficiency (which ideally means that we download each vote from exactly one peer)
• Adversarial resilience (if some of our upstream peers are adversarial, we are still able to download all honest votes in a timely manner).

It is easy to write algorithms for each extreme (basically, downloading all votes from all peers is maximally resilient, but minimally efficient; whereas trying to download each vote from a single designated peer is maximally efficient but minimally resilient); we want to strike a balance.

In particular, it would be useful to study the new TxSubmission logic by the Network team, ie the modules Ouroboros.Network.TxSubmission.Inbound.V2.*

• Get a high-level understanding/writeup of the logic.
• There are some differences between vote diffusion and tx submission (eg for tx submission, it is sometimes desirable/necessary to request the same transaction id again even if you already previously downloaded it, whereas this is never the case for vote diffusion).
  • Determine if there are further differences.
  • See if it seems plausible that we could reuse this logic (potentially with some additional parameterization).

Closed by IntersectMBO/ouroboros-consensus#1698