Use-Cases for Peer-keyed configurable connection bounds

[SgtPooki]

This is somewhat related to ipfs/kubo#9895, and spawned from a discussion @aschmahmann and I had in slack.

I only have limited understanding of all the things discussed in ipfs/kubo#9895, but I thought the idea of "options for applying connection bounds (keyed by peerId) could be useful for a variety of things" was interesting, and Adin challenged me with

If you've got better use cases in mind please file an issue. Would be interesting to know about and discuss since it boils down to the go-libp2p layer as well (i.e. go-libp2p won't really let you limit most connectivity options per dial and so I suspect they'd also want some motivating use cases to support changes)

My ideas are posted below.

NOTE: Some of the below may already be possible via other means, and some may not make any sense for those deeper in the stack. Hopefully this at least spawns some interesting thoughts, learnings, and discussions.

---

• Peer-Transport/Connection-Lock - I have a limit of C1 connections I can make on T1 transport, and i’m at that limit. I want to ensure any valid connection to P1 Peer, does not attempt to transition to T1 via upgrade or other means (maybe I’ve maxed C1 for a local swarm or other because it’s fastest). since P1 is not as vital (i dont want to waste T1 slots on them), keep a lesser transport Tx available for them
• Peer-Transport/Connection-Lock via Fitness Function - I have a set of peers PsM that I talk to regularly, and i can determine an optimal set of transports for each of those. I want to restrict individual peers within PsM into the transports i’ve determined work optimally for them
• Peer-Transport/Connection-Lock via upgrade requirements - I want to restrict any new connections coming in to a non-optimal, but highly successful, transport, and only allow them to update to a more resource-intensive but higher throughput transport after a validation period (i know they’ll stay up, i know they aren’t spamming me, I know their requests are important, I know they’re an important peer in the network, etc..)
• Adin - An example relying on this might be switching between connections if you say had a low latency connection but wanted to switch to one that had higher latency and higher throughput

---

The above aren't spawned from any particular need of my own, but I can imagine enterprise or other performance-sensitive users wanting these capabilities. I think some of these use-cases could be enabled in novel ways, without a huge swath of configuration options to accomplish (low effort to implement / maintain), but libp2p-core will certainly know better. Some ways I could see these being implemented:

1. Peer-Transport/Connection-Lock - We already have the concept of connectionGater (maybe only in js-libp2p?), what about a peerTransportGater? limiting certain peers (bonus for dynamic adjustments) to certain transports, or certain transports for certain peers, could be neat. Also, the below fitness function map could be configured in such a way to give known peers a fitness result of >9000 to ensure they're treated properly.
2. Peer-Transport/Connection-Lock via Fitness Function - A map of transports to fitness functionsMap<T[], (peer) => bool>> could be a fairly easy way to accomplish this.. We would probably need to tie into the peerStore for storing their "peer-rating"
3. Peer-Transport/Connection-Lock via upgrade requirements - Could be implemented with the fitness function map for transports

---

Some questions:

1. Are any of these scenarios possible today?
2. Is this something we could implement via default automated heuristics and allow users to override for their use-cases?
   • Do we have enough confidence in what fitness functions would be to build defaults...?
3. Are there any libp2p users out there now that would benefit from these configurations?
4. What dumb things did I say and can you please learn me better? ;)