Agent whois method

[Connoropolous]

Create a generic 'whois' method and pass our own AgentPubKey out of the cell and back in again at the resolver level. Either way I expect the code can be genericised to serve both needs.

_Originally posted by @pospi in https://github.com/h-REA/hREA/pull/307#discussion_r903575474_

[pospi]

To account for network partitioning with this feature, we will need to detect multiple links and handle gracefully.

For multiple links made from the same AgentPubKey this is reasonably easy to deal with- we can just pick the most recent. There should also be some validation around this per https://github.com/h-REA/hREA/issues/303#issuecomment-1164272860

For multiple claims against the same profile (which may occur after #310 is implemented) we should throw an error and require one of the conflicting agents to re-associate their profile to another one. #311 would allow such a re-association.

[Connoropolous]

@pospi remind me again, why is this needed? I don't see the need for it

[Connoropolous]

what is the intended function signature?

[pospi]

It's not a MMR milestone feature, but will be needed once hREA is integrated with other non-REA components in a fully-featured economic network (eg. file attachments, location mapping) so that resolvers have a way of mapping raw Holochain public keys to Agent profile data; eg. so that we can determine the author of an uploaded file.

[pospi]

Adding this to MMR since we will need it for #40. The only metadata we can get out of the local Cell is an AgentPubKey so the resolver for Revision.author will need to pass through whois in order to resolve the associated REA Agent.

[pospi]

Suggest we do the simple (unvalidated) version of this, merge, and then update the issue to deal with the validation specifics for future work.

[Connoropolous]

Suggest we do the simple (unvalidated) version of this, merge, and then update the issue to deal with the validation specifics for future work.

Agreed.

The only metadata we can get out of the local Cell is an AgentPubKey

what do you mean by the part about 'get out of the local Cell'? if there is resolving of an AgentPubKey to an AgentAddress to do, can't it be done internally to the zome of interest?

[pospi]

no, unfortunately only zomes co-located with the Agent storage zome can do that

[Connoropolous]

ah, I think I see. so it has to either, get resolved at the graphql resolver layer, or another option could be using some of your call plumbing and 'remote_auth' to resolve it before passing back through the WASM boundary

[pospi]

Yeah. And I would prefer to do it externally, since it's easier to cache data there and the additional load of fetching an agent entry for every record retrieved from the DHT seems like a not-very-good way forward.