fix: a way to prevent duplicated anchor events for multisig issuance

[lenkan]

This PR solves an issue that occurs when a multisig member is trying to join an issuance event after it has been fully signed. They need to do this to be able to import the credential in their database.

This is an alternative approach to the PR by @rodolfomiranda #271.

I will do the same for credentials().revoke() and registries().create() if you agree with this approach.

With these changes, I am able to complete this test case: https://github.com/nordlei/vlei-sandbox/blob/main/src/issues/multisig-catchup-problem.test.ts, so we should be able to resolve this issue: WebOfTrust/keria#283. The catch up mechanism would be to simply join all notifications for the multisig group.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.58%. Comparing base (32ceda1) to head (d2278e5).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #286      +/-   ##
==========================================
+ Coverage   83.55%   83.58%   +0.02%     
==========================================
  Files          48       48              
  Lines        4215     4221       +6     
  Branches     1055     1047       -8     
==========================================
+ Hits         3522     3528       +6     
+ Misses        689      663      -26     
- Partials        4       30      +26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lenkan]

Note: the reason I inlined this is because I think it makes it much more obvious what we are actually posting down to KERIA. I do not think the indirection of calling interact provides any readability improvements. But I am OK with either. Just provide your feedback.

[2byrds]

Good with me

[lenkan]

In the code, I have found several patterns for API operations that are posting Key Events.

IPEX Approach (e.g. apply and submitApply)

apply(): ApplyEventWithSignatures {
   // Create serders and sigs
}

async submitApply() {
   // Do fetch call
}

• signify-ts/src/keri/app/credentialing.ts

  Line 716 in 32ceda1

  async apply(args: IpexApplyArgs): Promise<[Serder, string[], string]> {

• signify-ts/src/keri/app/credentialing.ts

  Line 737 in 32ceda1

  async submitApply(

That approach would work here as well.

End role approach

Here we separate the creation of events into a private method to create the events named "makeXXXEvent". For example:

private makeEndRole() {}
async addEndRole() {
    const rpy = this.makeEndRole()
    // Do fetch call
}

• signify-ts/src/keri/app/aiding.ts

  Line 412 in 32ceda1

  async addEndRole(

• signify-ts/src/keri/app/aiding.ts

  Line 446 in 32ceda1

  private makeEndRole(

Create from events approach

For the registry creation, we have a pattern of createFromEvents where the actual fetch call is extracted to a separate private method:

• signify-ts/src/keri/app/credentialing.ts

  Line 615 in 32ceda1

  createFromEvents(

• signify-ts/src/keri/app/credentialing.ts

  Line 554 in 32ceda1

  async create({

Notes

I still think I prefer the method that I did in this PR. But I think we can discuss and decide on one pattern and implement that for all calls that involve posting key events. You can always create external helper methods to create the XXXArgs object needed.

[iFergal]

@lenkan For IPEX the advantage of how it is set up is that you can also send /multisig/exn with an embedded /ipex/apply using submitApply. KERIA will just handle them differently based on the route.

I kind of like that approach as it's a bit more flexible in general and quite clear from the business logic level: a clean function to create a message or event, and the API submission. This would be my preference in general.

But your change in this PR also makes sense to me if that's preferred by people. I don't like jumping too many levels deep in function calls as it's easy to get lost.

[2byrds]

@lenkan For IPEX the advantage of how it is set up is that you can also send /multisig/exn with an embedded /ipex/apply using submitApply. KERIA will just handle them differently based on the route.

I kind of like that approach as it's a bit more flexible in general and quite clear from the business logic level: a clean function to create a message or event, and the API submission. This would be my preference in general.

But your change in this PR also makes sense to me if that's preferred by people. I don't like jumping too many levels deep in function calls as it's easy to get lost.

@lenkan what do you think about advantages that @iFergal lists here?

[2byrds]

@lenkan I updated my signify-ts to this branch. And then tried to modify vlei-sandbox to use the new IssueCredentialArgs interface. But perhaps you already did this and can share? if i can prove that your catchup test works, i can include it in my rollback to prove that member3 is operational in the group again

[iFergal]

I discussed this offline with @lenkan a while ago. It is a bit curious that there's "2 ways" to do multi-sig IPEX which is probably unnecessary complexity. The benefit is less network calls though.

Though based on the eventual outcome of WebOfTrust/keripy#884 it might need to have the calls split anyway.

[lenkan]

@lenkan I updated my signify-ts to this branch. And then tried to modify vlei-sandbox to use the new IssueCredentialArgs interface. But perhaps you already did this and can share? if i can prove that your catchup test works, i can include it in my rollback to prove that member3 is operational in the group again

Hm, when I tried that, I only used npm link locally, so I never had that branch of vlei-sandbox pushed. Let me know if it is still an issue, then I could probably push a branch to vlei-sandbox that uses this for joining the credential.