Need a DIDComm version translator script (v1 <--> v2)

[dhh1128]

The work being done on DIDComm Messaging in the DIF DIDComm WG is creating a set of conventions similar, but not identical, to the DIDComm first popularized in Hyperledger Aries.

Protocol definitions in Aries don't need to be updated at a high level -- we expect the same interactions to be possible using the same sequence of messages, conveying the same data. However, the fields/structure in DIDComm v2 will be slightly different from the fields/structure in DIDComm v1. The correspondence should be largely mechanical.

What we'd like is a way to feed a DIDComm v1 plaintext message into a script, and produce a DIDComm v2 plaintext message as output. This would allow us to update all protocol docs in the Aries repo so that DIDComm v1 or v2 can be chosen as the perspective one takes on the protocol (similar to the way documentation on ZMQ lets you pick which programming language perspective you want to use, but the main narrative is identical; see https://zeromq.org/get-started).

Since the main audience for such a script would be Hyperledger Aries developers, I propose to add the script to the /code folder of this repo.

[kdenhartog]

I think this is a good idea. Curious if you've done any thinking about how the "from" field would be filled when going V1 -> V2 ? Similarly, thinking about how attachments may convert between the two given DIDCommV2 hasn't introduced the concept of attachments. These two were the main ones that I was scratching my head at and not able to come up with anything simple to solve the problem. Other than that though, I think it makes sense to go this route to greatly minimize regretful work.

[awoie]

A tool like this would be really great. Additionally, I'm interested in translating other DIDComm V1 features/decorators which are not-core-features of DIDComm V2. To me it is not 100% clear how decorators will be encoded in DIDComm V2 messages. IMO, we should create transformation rules. The following is just a proposal (other proposals are welcome):

1. If a decorator is a simple property only, remove the leading "~" symbol from the property name and add the property to the DIDComm V2 header section. NOTE: I don't know whether Rule 1 is needed at all.

2. If a decorator is a property with an empty JSON object, remove the leading "~" symbol from the property name and add the property as with its value set to true to the DIDComm V2 header section.

3. If a decorator is a property with a non-empty JSON object, add a new DIDComm V2 header for each child property of the decorator recursively. Use the parent object's property name concatenated with '_' as the prefix for the new DIDComm V2 header. If a property contains other JSON objects and so on, the final prefix of a DIDComm V2 header name contains all parent property names. Remove the leading "~" symbol for all DIDComm V2 headers under the top level decorator property.

For example, when looking at ~thread and ~please-ack, the transformation would be as follows:

Example:

{
  "~thread": {
    "thid": "b271c889-a306-4737-81e6-6b2f2f8062ae",
    "myindex": 4,
    "lrecs": {"2fQvCXfgvxz4dtBDDwcj2PJdG5qDrEsrQVjvWRhg9uhd": 3}
}

... translates using Rule 3 into ...

{
  ... headers ...
  "thread_thid": "b271c889-a306-4737-81e6-6b2f2f8062ae",
  "thread_myindex": 4,
  "thread_lrecs_2fQvCXfgvxz4dtBDDwcj2PJdG5qDrEsrQVjvWRhg9uhd": 3,
  body { ... }
}

Example:

{
  "~please_ack": {
    "message_id": "b271c889-a306-4737-81e6-6b2f2f8062ae",
    "on": [
      "RECEIPT",
      "6h",
      "OUTCOME"
    ]
  }
}

... translates using Rule 3 into ...

{
  ... headers ...
  "please_ack_message_id": "b271c889-a306-4737-81e6-6b2f2f8062ae",
  "please_ack_on": [
      "RECEIPT",
      "6h",
      "OUTCOME"
    ],
  body { ... }
}

Example:

{
  "~please_ack": {}
}

... translates using Rule 2 into ...

{
  ... headers ...
  "please_ack": true,
  body { ... }
}

Do you think an approach like this is useful?

The rules above also have issues with core features of the DIDComm V2 spec that overlap with existing Aries RFCs, e.g., see thread_id (DIDComm V2) vs thread_thid. So, I guess the converter should have extra rules when converting specific RFCs, e.g., threading.

Updated

• Removed statement about headers must be strings. DIDComm V2 currently says "Headers SHOULD NOT use more structure than necessary; simple headers are preferred."