This meeting uses UnSync conventions and takes place on our Discord channel; transcript of actual meeting chat published here. [ charter | meeting archive | schedule ]
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.
As Daniel Hardman is on vacation, I, Rodolfo M, will be launching this week UnSync meeting.
I submitted a simple PR for a section on DID Rotation. Please, have a look and leave comments.
Any contribution on missing guidebook sections is welcomed! Check which ones are still pending here.
I submitted PR for protocols retaled to the mediator, Mediator Coordination and Pickup. Timo G made suggestions and some comments that need agreement. Please, have a look at the PRs and leave comments.
After submitting the PR to add the Discover Features Protocol, that is nothing more than a link to the Spec, Timo G raised the issue that version 2.x is already in Aries. We may need to fix the verstion in the spec. Errata?
Proposed closure: discuss on chat and resolve on DIDComm WG Mondays call.
Several spec extensions are available in the spec repo. Some are linked from the spec, others reside unlinked. Should we have a section in didcomm.org listing avaliable extensions as we have with protocols?
Proposed closure: discuss on chat
Problem codes structure is well defined in the spec. However, since it's a generic reference, implementors may come up with different problem codes for similar problems. For intereporability reasons, it may be nice to have a set of basic problem codes that can be easily adopted by all (lazy devs also). I'm thinking of how universally adopted are http codes such as 400, 401, 403, 404 etc. Same idea can be applied to goal codes. What do you think?
Proposed closure: discuss on chat
I'm reposting the following idea from a previous agenda, by Daniel H. I'm raising the issue again to push it forward:
DIDComm v1 gained a lot of gravitas when many vendors committed to implement an interoperable snapshot. I believe we had 8 or 9 that ultimately released stacks that worked together.
These vendors came together in part because there was a cluster of useful protocols that worked together.
I think DIDComm v2 needs something similar. The most logical thing would be to begin pushing for a new AIP that is DIDComm v2-centric. It should include the protocols that are part of the v2 spec, plus the work on WACI that gives us credentials. We should probably add a few other protocols as well.
Is there anybody who attends the Aries meetings (when are they? I've lost track...) where AIPs are typically proposed, that could put forward a proposal for AIP 3 and champion it on our behalf? Are there other forums where we should also propose/champion the AIP? What protocols should we add to the basic set I proposed above? How about, for example, the stuff @Telegramsam has been working on to allow rich chat?
Proposed closure: discuss on chat.
Did you think this meeting was effective? How could we improve?
Proposed closure: Please leave your ideas in chat.