Feature request: a way for a multisig member to catch up updates

[lenkan]

As a member of a multisig group, I want to be able to catch up with events signed by other multisig participants.

Consider a group of three members A,B,C and a signing threshold of 2

• Member A signs event X and sends exn to B
• Member B signs event X and sends exn to A
• Event X is fully signed
• How does Member C catch up, for example if event X is a credential issuance, how do they import the credential in their database?

Perhaps there is already an API for this, but I could find an example where this is used.

From discord (Kent Bull):

This exists in KERIpy as a combination of kli local watch and kli multisig update. It's definitely doable in KERIA.

[lenkan]

This is functionality of a watcher.

What does that mean? Is that just meant as a pointer for how to implement or that it is not applicable to KERIA?

[m00sey]

This is functionality of a watcher.

What does that mean? Is that just meant as a pointer for how to implement or that it is not applicable to KERIA?

ha, you're too fast for me - I'm trying to formulate a better response.

[rodolfomiranda]

The workaround I'm using is that A or B sends exn to C. C "joins" the event and then queries the latest state of the multisig.
A better approach should be that A or B sends the exn with all signatures and witnesses receipts.

[lenkan]

The workaround I'm using is that A or B sends exn to C. C "joins" the event and then queries the latest state of the multisig. A better approach should be that A or B sends the exn with all signatures and witnesses receipts.

Cool, thanks for the workaround. So you would do the essentially the same operations that you would do when joining the event "immediately", but you can omit the exn message from C back to A and B?

[2byrds]

Per our dev meeting discussion:
This has some overlap with watcher functionality.
For TEL events, you could have a 'TEL watcher'. There would be a watcher for KELs and a watcher for TELs. This will require unwinding some stop gap solutions. And implementing the needed watchers.
The controller would not request information from a witness, instead it goes to it's watcher(s). It is the watcher of that KEL/TEL.
For multisig, each member is a contributor. The contribution is its own KEL. Each member should be watching the KELs of each member.
There are potential attacks if you aren't monitoring the key state of each member.
Group multisig has the multisig KEL which is in a group hab. There is additional information required to track the members of the group.
If Alice is a member, she should use a watcher to track the KELs of the other members.
Validators have the concept of memory and first seen tracking of key state. Should multiple KELs be allowed in the database? The logic of a controller/watcher is very close in direct mode, but in the other cases the watcher, watches the witness KEL events. The complexity of accepting a KEL into the db when watchers, witnesses, delegation, etc. are involved requires different first-seen rules in the 'memory'/db. We need to get cleaner at separating the db state per the role (controller, watcher, etc.) to avoid the difficulties the stop-gaps have introduced.
For a watcher to 'see' an event it must be fully-signed/witnessed/delegated.
Local watchers are okay, but they need a separate db 'memory' of the KEL... based on the rules of first-seen for a watcher. This is different from the controller and so they can't share the db. Put another way, the witness can see an event before it is fully witnessed. Watchers should not see a non-fully witnessed event.
A watcher service could sit side-by-side with a contorller/witness but must be logically separated. Witnesses could have a local watcher with its own db and own API.

From the controller perspective you could even receive an unwitnessed event. The witness will not 'see' the event unless it has at least one receipt. Watcher won't put it in the KEL unless it is fully-witnessed. This highlights why these dbs must be kept separate. This is per the first-seen rules for each role.

In multisig, the separation becomes more obvious. And so does the need to request KEL events from the watcher.

[rodolfomiranda]

Cool, thanks for the workaround. So you would do the essentially the same operations that you would do when joining the event "immediately", but you can omit the exn message from C back to A and B?

Yes, use the same "join" operation and you'll see that the event (key and tel) is created for that member however it has no witness receipts. You need to sync the state with a query or an oobi resolution.
Make sure that you have this PR merged in your signify-ts: WebOfTrust/signify-ts#271
(by the way, we need a review to merge)

[iFergal]

If the credential being issued in the original example is private and at issuance only known to the multi-sig issuer (and issuee), how does a watcher provide the actual credential to get into member C's DB? Do they still have to reach out to the other members?

Edit: On second though, the TEL doesn't even contain the ACDC, just the SAID of the ACDC and state. How does a TEL watcher find the ACDC itself, especially if it's private?

[2byrds]

@lenkan I have added this to the vLEI Top 10 - Needs Consideration I would be especially interested in how you rank it vs #213 or if there is another issue you consider higher priority

[lenkan]

Thanks @2byrds. I believe both features are needed for a production ready system! I would simply rank them based on the lowest effort first basis.

[lenkan]

I have created a script here: https://github.com/nordlei/vlei-sandbox/blob/main/src/issues/multisig-join-late.test.ts that reproduces an issue when multisig members do not synchronize their actions perfectly.

Here is how you can run the script

git clone https://github.com/nordlei/vlei-sandbox.git
cd vlei-sandbox
docker compose run --rm --build test npm start ./src/issues/multisig-join-late.test.ts

To outline the steps: we are creating a group with a 2 out of 3 signing threshold

1. Member 1 and member 2 successfully completes the group creation.
2. Member 1 and member 2 successfully completes a registry creation (can be any event really)
3. Member 3 is late on joining the group creation. Perhaps they had some internet connectivity problems, the reason does not matter really, this can happen in the real world.
4. Member 3 successfully completes the group creation.
5. ISSUE: Member 3 cannot successfully create the registry, the operation times out.

Does anyone have any pointers on what is going on here? I want to figure out both a short term and a long term solution. One short term solution is that we stop member 1 and 2 to move on to step 2 until the last member has also successfully created the group. One way to do this is out-of-band communication, but it would be even better if this can be handled within Keria. Is there a way through the Keria API to see which members have joined the icp event already?

[kentbull]

The code for kli local watch and also the code for kli multisig update are a great place to start.

I imagine the solution would be to incorporate this on a per-agent level in KERIA and then provide APIs for both viewing current state and updating it to a specific digest and sequence number.

[2byrds]

@Arsh-Sandhu mentioned in our meeting today about his work similar to the the 'kli watch' command.
Essentially, fetching events from witnesses to 'catchup'. There is a PR for sending an http request for the TEL/KEL events.
But you need the credential data via EXN, so you need to request them from the other members.... or import them from an export.