Skip to content

Latest commit

 

History

History
65 lines (41 loc) · 4.17 KB

2022-04-20.md

File metadata and controls

65 lines (41 loc) · 4.17 KB

y# Agenda — DIDComm User Group Meeting, 2022-04-20

This meeting uses UnSync conventions and takes place on our Discord channel; transcript of actual meeting chat published here. [ charter | meeting archive | schedule ]

1. First item of business: say "hi" on chat

Nothing fancy needed; just a wave. This helps us tell whether we have a quorum, interpret silence, hold people accountable, and know who we're collaborating with.

2. General Announcements

  • IIW next week (26-28 April).
  • WG is finalizing DIDComm v2 spec; please leave feedback on any open PRs if you participate in the WG.

3. Follow-up on action items

  • Daniel has 2 open PRs against didcomm.org. They have been reviewed by members of the UG and are approved to merge, but github is reporting that they are broken because they are missing a commit that makes a connection between HEAD and an event in the history. So this is an action item for me to fix. I intend to fix in the next few days and then ask for an immediate merge; please let me know if anyone wants further discussion on them.

  • @Telegramsam: what are your intentions with respect to decentralized-identity/didcomm.org#33?

  • @Will Abramson and @Brian Richter: can you summarize what happened with the didcomm.org issue about wildcard routes?

  • @Snorre: hope you had a wonderful wedding, and we're not expecting that you did much about DIDComm lately. But I'm just keeping alive your action item to write about the question you raised (when might it be appropriate to send plaintext messages).

  • @Lance Byrd: Thanks for socializing us in a few venues lately. Any update on work you and @Rodolfo are doing on getting started?Snorre: did you add our UG meeting announcement to the agenda of the next DIF Interop WG?

  • @Brian Richter: Any updates on work on the protocols section?

  • @John Jordan (BC Gov) volunteers to schedule a slot for a blog post at TOIP. Status?

4. v1 -> v2 converter

I am interested in writing a script (probably python) to convert DIDComm v1 messages into DIDComm v2 messages. I'm wondering about the optimal feature set. Right now I'm imagining that the script runs on the cmdline and accepts a DIDComm v1 message as input, and dumps a DIDComm v2 equivalent as output, along with a bunch of errors or warnings. The goal would not be to guarantee that the v2 message is perfect, but rather to show approximately what has changed. Decorators turn into headers, for example, and some header values change data types (e.g., timestamp strings get converted to seconds-since-epoch).

Proposed closure: Discuss these questions on chat:

  • Do we (also/instead) need a DIDComm v1->v2 service endpoint converter?
  • Do we need to dump out a list of transformations?
  • What do we do if a v1 protocol has no v2 equivalent?
  • Do we need to make an assertion (or description) about whether the conversion was lossy?

4. Making a v2 version of key Aries protocols

The following protocols feel important to me, and I'm wondering if we should try to build a v2 version of them (ones that modify as little as possible in their upgrade from a v1 incarnation).

  • Mediator Coordination Protocol (RFC 211)
  • Issue Credential and Present Proof protocols (RFCs 453 and 454) -> WACI, so these may not need anything else
  • Question Answer Protocol (RFC 113)
  • Action Menu Protocol (RFC 509)
  • Introduce Protocol (RFC 28)
  • Payment Decorators (RFC 75)
  • Revocation Notification (RFC 183)
  • Coin Flip Protocol (RFC 193)
  • Pickup Protcol (RFC 212)
  • "Help Me Discover" Protocol (RFC 214)
  • Coprotocol Protocol (RFCs 478, 482)

Proposed closure: I am wondering if anyone in our UG has an appetite to work on any of these, either alone or with me?

9. Last item of business: feedback

Did you think this meeting was effective? How could we improve?

Proposed closure: Please leave your ideas in chat.