If you're not familiar with link definitions, essentially, this is runtime configuration between actors and capability providers.
Link definitions allow an actor to interact with a capability provider and add some configuration.
For example, our HTTP server port which listens to HTTP requests.
When we create a link definition we need some information - contract ID, public key, link name of the capability provider.
Link definitions are not yet robust but there are a number of discussions happening in the community worthy of thought.
Link names are super useful in allowing multiple copies of the same capability provider.
You can completely separate instances with different configurations or isolate your instances.
Why is this useful? You can have two separate endpoints for the same actor which is important when scaling.
When scaling capability providers, we may need custom load-balancing and a different set of endpoints.
This gives us the flexibility to define different configuration and isolation requirements e.g. NATS inbound vs outbound.
When are they appropriate, how are people using them, how can we identify and capitalize on different use cases? Listen to the recording for a lively and informative discussion.
Takeaway from this discussion is to approach link names with use cases in mind. The use case that we're certain we need to address is the ability to know what link names the actor needs to use without inspecting the code, and this may start with including them in the claims list.