Fergal
Fergal
Hey @aleeusgr - ignore the above. We actually did spot this problem shortly after our release, so it should be fixed on main - https://github.com/cardano-foundation/veridian-wallet/pull/1086 I believe the issue was...
Fixed in 1.1.0 release. Please re-open if necessary
@SmithSamuelM I have a related question. If multiple credentials are bulk issued and anchored via a single Merkle root seal - is this a Merkle tree of various individual `iss`/`bis`/`rev`/`brv`...
@SmithSamuelM Yep I know - I was more so wondering if you had a view of how those public interoperable semantics should look like. But no worries if nothing has...
It's the same HTTP endpoint, so it's up to the client using Signify to decide whether to pass the `/multisig/exn` exn to `submitGrant` or pass the `/ipex/grant` exn and send...
What I meant is `/identifiers/{name}/ipex/grant` is one HTTP endpoint that has a [switch](https://github.com/WebOfTrust/keria/blob/0de085632706dbc148dc9cbba7ed7ee3134639fa/src/keria/app/ipexing.py#L68-L72) statement to decide whether to use `sendGrant` or `sendMultisigExn` based on what `exn` message it receives from...
The problem here is the long running operation is related to the OOBI and not the contact. The OOBI has been previously resolved (and is never removed (we don't unresolve...
Yeah I wouldn't be opposed to that since the second call would be necessary anyway for the attributes, and the OOBI resolution is idempotent if it fails before creating the...
For now at minimum we could create the new op type. But if we are moving towards removing contacts from KERI in the long term, I think it makes sense...
@lenkan I looked at this yesterday a little more closely. The POST/PUT contact APIs are synchronous and once you get the 200 everything is done, so there's no op type....