Handling anchor address

[nfrgosselin]

Moving this discussion from #64

Kurt
we cant use the anchor as identyId
since the anchor can change during the pool period

if the anchor changes during the pool period, this check on submitMilestone will fail.

to still be able to rely on the anchor we could maybe remove anchorToIdentityId[identity.anchor] = bytes32(0); on the Registry in updateIdentityName
-> we should carefully think about pros and cons

Aditya
@nfrgosselin @zobront @codenamejason :

Currently when an identity name is updated -> the anchor is changed.
And we lose the link between the old anchor and the identityId. This was intentionally done (as explained by @KurtMerbeth in the above comment)
Since the recipientId is an address, we are forced to use the anchor as opposed to identityId (which is in bytes) from the Registry.

To avoid this, we could just remove https://github.com/allo-protocol/allo-v2/blob/main/contracts/core/Registry.sol#L138.

Can't think of a downside for this.
The pros :

we keep a history of all the anchors associated with an identity
when an anchor is updated, it won't affect the pools where the identity is currently taking part in (cause the history is preserved in the mapping )

[nfrgosselin]

Pulling over from the PR:

from @zobront
I think it is a problem. Let's picture this situation:

my identity id = 1 and name = Zach Obront => this outputs Anchor 1
i change my name to Elon Musk => this outputs Anchor 2
any attestation to Anchor 1 is still considered valid, which means I can submit to projects as Elon Musk (because the anchor is pointing to the new struct that has been updated)
I believe the current setup in this contract also limits that at most one recipient can be registered per recipientId / anchor, which may limit a situation when there are multiple members from one identity that want to submit.

It seems like the ideal solution is that, rather than tracking recipients by recipientId, we track them by recipientAddress. That means recipientId is only a blocker when submitting, to make sure the identity is valid, and after that it's just there for name/metadata.

This still leaves the problem that the link would break if they changed the name (because that would also change the anchor). But we probably want the behavior, not to just assume the new name is valid?

The only solution to that I can see is that you can never change a name in the Registry. It has to continue to exist forever. You can simply create a new identity in the Registry, with a new name, and then base things on that.

I actually think that may be better, as it ensures historical ones are always there, and doesn't seem to harm users at all.

Thoughts?

from @nfrgosselin

The only solution to that I can see is that you can never change a name in the Registry. It has to continue to exist forever. You can simply create a new identity in the Registry, with a new name, and then base things on that.
I actually think that may be better, as it ensures historical ones are always there, and doesn't seem to harm users at all.

This is actually where I thought we ended up originally. I like this solution, as we can normalize an attestation pattern that allows old identities to validate their new identities