Registry association in places where the role is unknown

[alexgraham-da]

In places where the role is known, I've been adding registry lookups to use registered names instead of party names, which has made the UI feel a bit more polished.

However, there are a number of places where the role a party is playing is unknown, such as the "Provider" in Holdings:

Since the provider isn't tied to one single role (see https://github.com/digital-asset/da-marketplace/issues/52), it's impossible to know which registry contract to look up to use the registered name. This is complicated by the fact that a party can have multiple role contracts, since you wouldn't just be able to just use the name of whichever registry contract the party does have.

Is there any way we can figure out the correct role in these instances? Aside from being able to see the correct registered name, there may be other value in knowing what role a party was playing when taking part in an action such as being a provider.

The MarketRole type could be useful here. In the case of Provider specifically, since Account is built into DA.Finance, perhaps we could change getAccountLabel to include the role. This would need to change in a few places, but at the very least in Holdings we would have the Role info when performing the allocation (after https://github.com/digital-asset/da-marketplace/issues/52).

[dimitri-da]

Thanks for raising this. The design of the label format in an account Alice@Custodian was chosen to serve its purpose for the initial version of the models. I am all for adjusting it if it no longer works for what we need it. I am not convinced however that adding the party's role on the account label is the right way to go about this. As you already mentioned a party can potentially have more than one roles. These roles are also not predetermined (perhaps they should?) as a party can later decide to play an additional role. This means that we would have to keep account labels in the system in sync with the roles that the parties have.

A way perhaps to go about this is to consolidate the different registry templates into a single one keyed by (operator, party) that will contain all the information of a party including the various roles they have. Then you would be fetching a single contract every time.

Another way could be to make allocation a two step process where the person first selects a provider role (ie allocate to a broker or to an exchange or to a custodian) and then upon role selection fetch all instances of the corresponding registry contract template and then display all the available parties

"Aside from being able to see the correct registered name, there may be other value in knowing what role a party was playing when taking part in an action such as being a provider"

^ agreed on this one but let's have an actual use case before we change the label format

[alexgraham-da]

Thanks for taking a look at this. A few thoughts:

Another way could be to make allocation a two step process where the person first selects a provider role (ie allocate to a broker or to an exchange or to a custodian) and then upon role selection fetch all instances of the corresponding registry contract template and then display all the available parties

I believe @alexmatson-da is working on a version of this for https://github.com/digital-asset/da-marketplace/issues/52, but you are still going to lose that information once you make the allocation to the party.

The problem I'm seeing (and it's possible I'm missing something or overthinking), is that Bob may be acting as a Broker and an Exchange with his single ledger party - let's say Alice allocates her asset to Bob's Brokers Inc. in the UI which can now differentiate in the provider selection. But her asset is still allocated to Bob's party, not his role contract, so the system has no way of knowing if her asset is in Bob's Brokers Inc., Bob's Exchange or even Bob's Bank. This seems like an important distinction regardless of how it's presented in the UI.

I can see that changing the way labels work may overly complicate things. I do think that if we're going to have parties be able to play multiple roles (which there is certainly value in), we'll need to keep track of what role they're playing when they take certain actions (or have certain actions taken on their behalf).

A way perhaps to go about this is to consolidate the different registry templates into a single one keyed by (operator, party) that will contain all the information of a party including the various roles they have. Then you would be fetching a single contract every time.

This might make lookups easier, but I'm not sure it helps in this specific case - you would still need to know what information to extract from that contract (e.g. exchange info or broker info).

[dimitri-da]

I see your point and I do see the value of knowing if a deposit is for Bob the Investor of Bob's brokers. As I said before the label format serves the initial design. If you come up with a proposal we can go ahead and prioritize it. This will also depend on how we integrate Company A vs Employees of Company A to the app so we would have to take it into account