DIDComm V2 messaging support

[Artemkaaas]

Hello, Team You are doing really great job! I see that the main direction of project evaluation is related DIDComm messaging of the first version. Do you have any plans regarding moving to the second version of DIDComm or even to the third one?

For our project, we took the Aries Framework as the basis and implemented our custom protocols with the integration of DIDComm's second version.

In order to integrate DIDComm V2 we had to make several important changes some of which contradict current approaches :

• We reworked Message Sender / Message Receiver to support both types of messages DIDComm V1 and DIDComm V2.
• We added Key Service - an extra module/layer for keys generation, management, and storing in the collection. Libindy wallet API is used to store keys ( same as for other AFJ collections). We had to do it because the package we used for packing DIDComm V2 messages requires the implementation of methods for receiving the private key parts. Libindy which is currently used for DIDComm V1 does not provide an ability to get it. Proper way here was integration of DIDComm V2 directly into Libindy, but it is more difficult and requires much more work.
• We also added DID Service - managing DIDs in a similar manner.
• We tried to preserve existing DIDComm V1 protocols working but have not tested them for a while. They may be broken, but there should not be difficult issues. So DIDComm V1 messaging is still used for old V1 protocols like connection, issuance, and verification. We have not adopted them for DIDComm V2.
• Connection: DIDComm V1 protocols (like issuance, verification) depends on the Connection module and record. There is not any connection protocol or object for DIDComm V2. So DIDs are just passed directly into protocol starting functions.
• We adopted the Request Mediation protocol for DIDComm V2 (but we broke DIDComm V1). It should be possible to fix.
• We adopted the Trust Ping protocol for DIDComm V2.

Taking into account these important points, would you be interested if we contribute our changes to the upstream? We are asking it in advance because it may take significant time to prepare our changes for the merge request.

[rodolfomiranda]

Great job! Were you able to run the rust library in react native? Last week in the AFJ call we had a discussion about DIDComm v2 implementation. Your contribution is more than appreciated!.

[Artemkaaas]

@rodolfomiranda yes. here is react-native package working on both android and ios.

[2byrds]

Yes, awesome work @Artemkaaas! Here are some notes from that meeting last week And we'd love to have you at the meeting this Thursday (i'm hosting and can put you at the top of the agenda, to discuss)

[genaris]

This is becoming a 'hot topic' within our community, as it took most of last week call and we were willing to continue the discussion 😄. There is a thread in Discord channel as well. Different approaches are under analysis and of course one of them is about using SICPA library.

If i'm not wrong, one of the main concerns about SICPA library was about React Native support, but if it's already there, we are good to go. Other issue is that, as you may have noticed, there was a massive amount of changes since your original fork (including the refactoring being done in 0.3.0-pre), so some interesting integration work should be done there.

BTW the branch containing your development is this one, right? I've seen in one of your latest PR that you've added a summary of changes in both your fork, which is really useful.

Thanks for opening this issue. It's a good way to explore different options and keep track of our thoughts and findings on this area.

[2byrds]

@TimoGlastra and @genaris please provide guidance for inclusion of this work in 0.3.0

[berendsliedrecht]

@TimoGlastra and @genaris please provide guidance for inclusion of this work in 0.3.0

I don't think it is a good idea for this to be included in 0.3.0. We can talk about it during the next next WG Call, but I think it should be when we modularised the framework.

[TimoGlastra]

We're really interested in a contribution of DIDComm v2! Not sure if we can make it in 0.3.0, as we want to get it released as soon as possible.

One thing I'm worried about is the conflicts that are between your fork and the current 0.3.0 branch. We've made A LOT of changes since (big architectural changes), and it seems you also made a lot of big architectural changes. Some points mentioned we have a similair solution for, and we need to be careful to not create technical debt.

That said, really looking forward to this. I think my preferred approach would be to start making incremental PRs with not too much changes so we can understand what is being contributed here. If that's not possible I think we should first have some calls and see what the changes and impact are of these PRs.

As @blu3beri mentioned, we should discuss it during the WG call. Are you available next week to join? Not sure what has been discussed this week, if it's already been discussed I'll re-watch the recording

[2byrds]

That sounds reasonable. In the meeting this week @Artemkaaas introduced his work to us and his desire to contribute it back. It was similar to what is in this issue, with some extra details and description. We weren't sure the right path/timing from this point. So we now have a great starting point :)

[2byrds]

@Artemkaaas we'd love for you to join the newly formed aries-didcomm-v2 channel as I'm trying to collects the threads regarding DIDComm v2 support in ACA-py and AFJ so that we can discuss how to push forward together and accelerate adoption https://discord.com/channels/905194001349627914/1032736844053483621