Exchange message operations should use a different oid

[iFergal]

Almost everywhere in KERIA we create long running operations with an oid value of the related identifier.

The problem with doing this for exchange messages (maybe other scenarios too?) is you cannot have multiple long running operations for exn messages at the same time. And that's very probable for multi-sig when the operation does not complete until at minimum a threshold amount of signers have signed.

Easiest solution might be to use the SAID of the exn message (or maybe the embedded exn in the case of multisig) instead of embedding it in the metadata of the op.

Are there any concerns with this?

---

Here is an example test: cardano-foundation/signify-ts@9b641cd

• 2 of 2 multi-sig
• 2 credentials issued
• Member1 admits both, member2 admits none (so neither admit has completed)
• The first long running operation has been replaced by the second (metadata updated)

[2byrds]

Almost everywhere in KERIA we create long running operations with an oid value of the related identifier.

The problem with doing this for exchange messages (maybe other scenarios too?) is you cannot have multiple long running operations for exn messages at the same time. And that's very probable for multi-sig when the operation does not complete until at minimum a threshold amount of signers have signed.

Easiest solution might be to use the SAID of the exn message (or maybe the embedded exn in the case of multisig) instead of embedding it in the metadata of the op.

Are there any concerns with this?

Here is an example test: cardano-foundation/signify-ts@9b641cd

• 2 of 2 multi-sig
• 2 credentials issued
• Member1 admits both, member2 admits none (so neither admit has completed)
• The first long running operation has been replaced by the second (metadata updated)

exn (and embedded exn) SAID seems like an improvement to me @iFergal

[iFergal]

In the case of IPEX, the operation is actually for the embedded exn anyway so SAID makes sense. I have started working on this locally, will continue... I think it actually makes sense to do this everywhere, and not just exn.

For example, you could issue 2 rotations in a row for an identifier - second replaces the first. But maybe the second fails due to a bug in Signify-TS. Now you can't track the first rotation which successfully completes.

[SmithSamuelM]

Using the SAID for exn transaction id presages the keri version 2 optional exn format which adds an exn inception event to exn transactions so that a set of exns chained off from their inception can be tracked by the said of the inception event.

[iFergal]

Completed with #289