# AFJ DIDComm V2

Thougts on implementing DidComm V2 in AFJ

## Notes from ACA-Py approach

See [this document](https://docs.google.com/document/d/1piGZ-0FW9DWEFRetviV1Vjxv7DDkIFQDWUs38VGqZ-Y/edit#) for notes about the implementation of DIDComm V2 for ACA-Py.

- Use same message class, but use a different serializer for v1 / v2
- Mechanically transform DidComm v1 messages to DidComm v2 messages

## DidComm v2 message

Each protocol can choose to extend either the `DidCommV1Message` or the `DidCommV2Message`. The `MessageSender` now accepts either of those, and can use different underlying code to handle the v1 and v2 messages. However, the shared didcomm methods allow common processing between the two.

interface DidCommMessage {
    id: string
    type: string
    
    threadId: string
    
    // ... other common didcomm methods and properties ... //
}

class DidCommV1Message implements DidCommMessage {
  @Expose({ name: '@id' })
  public id: string
  
  @Expose({ name: '@type' })
  public type: string
  
  public get threadId() {
    return this.thread.thid ?? this.id
  }
}

class DidCommV2Message  {
  public id: string
  public type: string
  
  @Expose({ name: 'thid' })
  public threadId: string
}

- Do we need to add a mechanical way to transform DidCommV1 to DidCommV2 format?
- Adds a lot of complexity -- Personally I'd like to define different implementation for V1 and V2

## V3 Issue Credential & Present Proof protocols

- Module (and public API) can stay exactly the same
- Move more shared logic to the module level from the service (auto-accept, state checks, etc...)
- Add a CredentialProtocolVersion and ProofProtocolVersion V3
- Add V3 messages, handlers and services (copy from V2 protocol -> transform to DIDComm v2 structure, so it can version seperately)
- Reuse the format services
- Messages are not stored in the credential and proof exchange records so we can reuse the same record types
- Minimal overhead to the user whether v1 or v2 or v3 is used (all same api)
- Extend `DidCommMessageRecord` to also support DidCommV2 messages
- It just stored Json so should be relatively simple

## DidCommV2 Envelope

- No support for DidCommV2 envelope yet
- Extend the wallet interface to support DidComm v2 envelopes in addition to DidComm v1 envelopes
- Working on adding Aries Askar
- Usability of SICPA didcomm js library for AFJ?
- Can't run Wasm natively in React Native
- Looking at adding a JSI interface to add a WASM interface for React Native
- Would make future additions to AFJ a lot easier as we automatically support Browser, RN, Node
- Will be a lot of work

## DidCommV2 Routing and Connections

- Already supports generic did resolver with support for `did:key`, `did:web`, `did:sov`, `did:peer`
- Working on generic did registrar with suport for `did:key`, `did:sov`, `did:peer`
- Extend connection record to store the supported didcomm profile? (ACA-Py)
- Includes both the
- Probably not needed, we can exract this from the did document
- Add support for OOB v2 protocol
- Just need to send and accept an invitation
- https://github.com/hyperledger/aries-agent-test-harness/blob/main/aries-test-harness/features/oob-v2.feature
- Create a connection record
- Set their did to did from invitation
- Generate peer did (or use already existing public did) for our did
- Can still use Oob V1 invitation with `didcomm/v2` accept
- Using didcomm v2
- Look at `accept` in oob invitation
- Look at `accept` in Did document services (if using public did for connection we can auto update by adding a didcomm v2 service, the other agent should then pick it up)
- Updating peer dids to add a service
- Is this possible in DidComm v1?
- ACA-Py call mentioned defining a decorator to update to new envelope
- Community Coordinated Update to migrate unqualified dids to qualified dids
- Can add a method to the message sender `sendMessageToDid` (in addition to `sendMessageToService` and `sendMessage`)
- How different is DidCommV2 routing compared to DidCommV1 routing?
- Add a DidCommV1Router and a DidCommV2Router?
- Handles the packing, routing, mediators, return routing etc... for a specific didcomm version
- Abstracted in the MessageSender, so the framework user

## DidComm v2 implementation (Jakub)

I briefly looked at didcomm-rust, and I don’t understand all the differences introduced by DIDComm v2. Still, it doesn’t have to be so difficult to re-implement missing parts of DIDComm v2 instead of adding and using the whole didcomm-rust library, assuming we’ll add support for aries-askar. AFJ’s `MessageReceiver` and `MessageSender` do have quite similar responsibilities as public methods of [didcomm-rust library](https://github.com/sicpa-dlab/didcomm-rust/blob/main/wasm/README.md). It can be possible to update AFJ's internal structure and allow to call `didcomm.sendMessage(message, toDid, fromDid)` from other parts of the framework (`MessageReceiver` and `MessageSender` would be part of `didcomm` - look at [re-architecture issue](https://github.com/hyperledger/aries-framework-javascript/discussions/722)). DIDComm module would encrypt the message based on DIDDocuments resolved from `toDid` and `fromDid`. I don’t know if it would be required to somehow modify internal `sendMessage` internal behavior from outside.