Joined member of multisig can't access registries

[daviddm]

There’s no way for a new member in a multisig to catch up with all previously created registry in a multisig.

version: Current stable release latest/0.2.0-dev4 (2024-11-05)

I’ve created a test case to highlight that there’s no functionality for a multisig to extend or change their members and continue normal issuance operations.

Steps to reproduce

1. Create multisig with member A and B
2. Member A and B creates a registry for the multisig
3. Member A and B adds new member C to the multisig
4. Member C successfully joins the multisig
5. Member C lists the registries for the multisig

Expected result

Member C gets a list with registries belonging to the multisig.

Actual result

Member C gets an empty list of registries for the multisig.

Reproduction

https://github.com/nordlei/vlei-sandbox/blob/multisig-join-credential/src/issues/multisig-join-registry-problem.test.ts

Related

#283

[2byrds]

@m00sey and @Arsh-Sandhu maybe you can help us know how this is done in KERIA/keripy? Perhaps there are scripts to update the underlying database? Any inspiration is welcome.

[2byrds]

@Arsh-Sandhu will add details for how he did this here
This was part of the migration from commandline keripy wallets to KERIA wallets.

[Arsh-Sandhu]

To migrate an existing registry of the multisig AID to the wallet of a newly added member, follow these steps:

• From the wallet of an existing member of the multisig, export any or all issued credentials of the multisig AID in CESR format. In Signify, you can use the Get method of the Credentials class and pass arg includeCESR=true.
• Send a PUT request to http://<keria-agent-address>:<keria-agent-port>/ with the headers CESR-DESTINATION: <local AID of the newly added member in the multisig AID> and Content-Type: application/octet-stream, and include the exported credential data in the body. For example:
  curl -X PUT http://<keria-agent-address>:<keria-agent-port>/ --data-binary @credentials.cesr -H "CESR-DESTINATION: <local AID of newly added member into multisig AID>" -H "Content-Type: application/octet-stream"
• This will store the exported credential(s) and the registry in the new member's wallet.
• At this point, the registry does not have a name.
• In Signify, to update the name of the registry, use the rename method of the Registries class: rename(name: string, registryName: string, newName: string). Pass the following arguments
  • name: Alias of the multisig AID
  • registryName: Registry prefix
  • newName - New registry name

[2byrds]

To migrate an existing registry of the multisig AID to the wallet of a newly added member, follow these steps:

• From the wallet of an existing member of the multisig, export any or all issued credentials of the multisig AID in CESR format. In Signify, you can use the Get method of the Credentials class and pass arg includeCESR=true.
• Send a PUT request to http://<keria-agent-address>:<keria-agent-port>/ with the headers CESR-DESTINATION: <local AID of the newly added member in the multisig AID> and Content-Type: application/octet-stream, and include the exported credential data in the body. For example:
  curl -X PUT http://<keria-agent-address>:<keria-agent-port>/ --data-binary @credentials.cesr -H "CESR-DESTINATION: <local AID of newly added member into multisig AID>" -H "Content-Type: application/octet-stream"
• This will store the exported credential(s) and the registry in the new member's wallet.
• At this point, the registry does not have a name.
• In Signify, to update the name of the registry, use the rename method of the Registries class: rename(name: string, registryName: string, newName: string). Pass the following arguments
  • name: Alias of the multisig AID
  • registryName: Registry prefix
  • newName - New registry name

You are a gem @Arsh-Sandhu !

[daviddm]

@Arsh-Sandhu I just tried this and I'm not really sure which endpoint this will invoke.
Which version of KERIA did you use for this?

[Arsh-Sandhu]

@daviddm we used KERIA v1.1. This endpoint is also in the latest code of main branch. It is in HttpEnd class of indirecting.py

[2byrds]

@daviddm suggests to resolve this, it would good to have a test case that executes this on the admin/3901 API so that the controller can execute the equivalent steps listed by @Arsh-Sandhu

[kentbull]

You can generalize this into a multisig catch up functionality for synchronizing the entire multisig group state to a new participant. This goes beyond simple KEL catch up (kli local watch and kli multisig update) to include the following things:

• KEL (from kli local watch & kli multisig update)
• Registries
• All ACDC TELs
• any other multisig state that every group member should have.

The existing functionality in kli local watch and kli multisig update is not sufficient to synchronize all of the multisig state so we will have to write more synchronization code.

[kentbull]

This sort of functionality needs to exist in KERIpy for multisig groups in general. It applies to GroupHabs as well as SignifyHabs and SignifyGroupHabs.