Labels & Policies

Background

Currently, connections are generally considered to be equivalent, "global" resources shared by all users of a single libp2p host. However, this isn't always desirable:

1. Some connections may be transient (solved manually for now), slow, or limited.
2. Some connections may be expensive.
3. Some services may want to use separate transports and/or connections for different types of messages (https://github.com/libp2p/go-libp2p-pubsub/issues/455).
4. Some connections may be "important" and should not be cut. There's currently no good way to specify "policies" in the connection manager.

Proposal

Introduce a concept of "labels" to libp2p implementations where:

1. Transports, connections, streams, etc. can acquire one or more "labels". Or, more generally, (label, value) tuples.
2. Requests (connection attempts, new streams, etc.) may specify policies over these labels.

Examples

Example 1: Transient Connections

1. The relay transport (maybe?) and transient relay connections would be labeled with "transient".
2. The default dial and "new stream" protocol would reject "objects" with the "transient" label.

Example 2: Service-specific connections

1. Hosts needing special-purpose connections would register one transport per connection type per protocol. E.g., there might be a TCP transport for "data" and a TCP transport for "pubsub".
2. When creating new streams, services would be able to specify "policies" describing which type of connection they want.

Questions:

• How do we distinguish between these transports in peer records? I assume we'd need to advertise the labels somehow.
• How do we make sure both sides agree on the labels? Is that necessary? We can probably use identify but this could be... interesting.
• How do we prevent other services from using connections with "reserved" labels? We'd probably need some form of "default" or "general" label where all connections would inherit this label by default and all request (dials, etc.) would require this label by default.

Example 3: Priorities

A request (dial, etc.) could specify a priority for labels. E.g., prefer connections that don't require file descriptors, reject transient connections.

Why Labels

So, the simple solution here is to allow the user to pass a bunch of filters in the context (or in some form of policy). E.g., they could pass a filter/comparator to filter/sort transports, addresses, streams, connections, etc.

However, labels let us abstract this away a bit. Instead of having to handle transports, addresses, streams, and connections, the filters/comparators would operate over labeled abstract "objects".

No files, tests, or entry points are named. Start by reviewing the existing connection manager, transport, stream, and peer-record abstractions, then resolve how labels and policies should be represented, advertised, agreed on, and enforced. Done means an accepted design and implementation scope for the proposed label-based policies.