James Ebert

I'd agree, I think my biggest concern will be with existing mediator deployments that don't use did:key yet--so if we can ensure backwards compatibility then I agree with Timo that...

Hmm--I think that having a cli argument _or_ just changing to use did:key & considering it as a breaking change would be appropriate. This would require that the AFJ/Bifold agents...

> Since this is only about mediation, perhaps we formalize this in the aries-mediator-service. Tag and release the 1.0 using the existing, and tag and release 2.0 with `did:key...". That...

I think the issue here (as far as I understand it) is that this only works to keep an active websocket connection open, while if it is actively disrupted (wifi...

After some troubleshooting on my end, the functionality here is that the server needs to implement the ping-pong intervals/config, with no change on the client-side AFAIK. This is something we're...

@TheTreek has done some testing with this branch & ACA-Py, and everything is working as expected (using connections v1), except that there is a minor version mis-match between AFJ &...

> Can you characterize the 1.0/1.1 issue? Which library is doing what? Yeah, here's my best understanding of the issue @swcurran, as described in [RFC 0003](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0003-protocols#semver-rules-for-protocols). According to my testing--the...

> The only thing I wonder is since AFJ received an OOB 1.0, should it respond with an OOB 1.0? That would require that a protocol be able to support...

Would Indy revocation also fall under this--or is it specific enough to Indy due to ledger requirements? I would think the answer would be yes (AnonCreds Revocation or AnonCreds Indy...

@TheTreek & I were able to recreate the issue--we've determined it's caused by the asynchronous ledger loading addition in AFJ (#580). So, adding `connectToIndyLedgersOnStartup: false` will work as a quick...