Partner Alias/Label/Name

[usingtechnology]

The name a user sees for a Partner is determined in the frontend (utils/partnerUtils) and it inspects the partnerAPI object and various sub-objects (profile, credential, etc). This can still lead to inconsistencies, depending on how populated the partnerAPI object is, so various endpoints can return a full partnerAPI, or just a single fetched object from the table. It also requires that we call partnerUtils.getPartnerName anywhere we need the partner's name in the UX.

We should move the logic for partner name into the backend and it should be stored and updated as necessary. Return the value at the top level partnerAPI object that and ensure the value is always fetched.

[etschelp]

See also https://github.com/hyperledger-labs/business-partner-agent/issues/77

[etschelp]

This is a never ending story. There are a few gotchas. So I already changed the behavior in the backend that

1. A alias is always the value we get from the frontend and it should never be changed by the backend.
2. The label is always the label we receive from aca-py, and it might be empty depending on the direction/type of the connection

The state of the partner also depends on a couple of things:

1. Type of the opposite agent
2. State of the opposite agents public profile
3. State of the connection

But I agree that it is probably better to move this into the backend. But I would not persist the name rather calculate it. Meaning I would move the naming strategy into the backend which then sets a partnerName field on the PartnerAPI object accordingly during conversion.

In the end whatever we decide on doing there should be only be one place that sets the partners name.

[usingtechnology]

Yes, sorry to bring it up again. It must be a never ending source of frustration for you! Obviously you've thought about this a lot more than I have. The logic for the business partner name to display is very complex. When we initiate the connection/partnership, we set the alias. On the other side, that's where it gets complex right? Because we don't have the alias, and the label may or may not be set, so then we start looking for profiles and documents... but if we do that series of lookups on the incoming connection... (check for public profile etc), can't we just set the alias? Then the user can change it when the want to whatever they want? So that we always use the alias field for partner name?

Again, I know you've been dealing with this forever, so you know all the gotchas, but I would think (and could be wrong!) that we do all the logic on the incoming connection to set the alias the best we can, then the user can change it when/if needed.

[domwoe]

The issue I see with this (which might not be very frequent) is the following:

• Alice has set up a profile with legal name "MyCompany"
• Alice adds "AnotherCompany" as a partner
• Bob of AnotherCompany sees the new partner MyCompany
• Now Alice changes the name in the profile to MyNewCompany

I'd argue that, if Bob has never manually renamed MyCompany to something else, then MyCompany should be renamed to MyNewCompany. However, if Bob has given MyCompany an alias it should not be affected.

[usingtechnology]

That is a very good example.

Could we could use notifications for this? That "MyCompany" has changed their name? And when would Bob actually know that Alice changed the company name - only on a refresh of the partner? Are there automatic or scheduled refreshes of profiles?

My biggest concern would be the runtime dependency on external data to determine the display name. All data should be local so logic is quick.

[etschelp]

First, with didexchange and the possibility of public did's profile resolution now happens on both ends of the connection. So in both cases we should agree on a partnerName resolution order, what we have now is:

1. Alias set by a user (set when creating the connection, or editable when clicking on the pencil in the partners details)
2. Legal Name from public profile if set
3. aca-py label, --label flag or overwritten when creating the connection with the label option
4. did, public or peer

I would move this logic from the partnerUtils.js into a PartnerNameStrategy.java which is then used by the PartnerConverter.

Second, how to keep data in sync. This is too is a never ending discussion :) If we think aries I would argue that a partner would announce changes via a proof proposal. I think json-ld comes in handy here because the context would be the same in the proposal as well as in the profile. So if there is a match we could do an auto update. Doing a partner refresh e.g. once a day would be a hack until we have switched to v2 protocols.

[usingtechnology]

Ok, that sounds like a good plan.

[domwoe]

@etschelp Can we close this?