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.
FYI. DIDComm v2 spec is nearly frozen (into a "Working Group Approved" status). All major PRs were closed out, and most issues were either deferred or fixed recently. ETA: a couple weeks?
Please check last meeting's agenda for items with your name on them.
DIDComm has never had a session construct. This prevents us from analyzing perfect forward secrecy in a straightforward way, and it creates a bunch of suboptimal key re-negotiation work in v1 and v2.
This past week, we had the beginnings of a discussion about the concept of connections, which may or may not map onto sessions.
I would like to have a deeper discussion about this in our User Group. We're not writing specs here, but what I'd like to know is this:
Based on your implementation experience, what do you consider desirable properties of a session, if DIDComm had one? For example, do you think a session should map to a relationship (Alice:Bob is a relationship, and it has only one "session" at a time)? Or can there be multiple sessions between Alice and Bob at the same time? If the latter, what data accumulates discretely in each, and what data should be shared across all sessions that are rooted in a common relationship?
Proposed closure: discuss on chat.
Brian brought up the somewhat neglected topic of spam, which we discussed at length in DIDComm v1 days. I'm interested in exploring this topic more, too. Do individual agents need a mechanism to prevent unwanted DIDComm messages from arriving in the first place -- or is it good enough that the agents can delete the messages without bothering their "master", so the agents see spam but they are perfect at filtering it for their master? What is the proper level for imposing a cost on senders of DIDComm spam -- should that be imposed by a load balancer who's acting as a relay, somewhere along a route? Or by a mediator (better mediators = better at managing spam)? Or by Alice's cloud agent, since Alice may define differently from other clients of the same agency?
Proposed closure: discuss on chat.
Did you think this meeting was effective? How could we improve?
Proposed closure: Please leave your ideas in chat.