Summary:
Planned topics
- Grooming Work updates (30 5 mins)Work updates
- Grooming (10 20 mins)
- Design discussion (10 20 mins)
- Open Discussion (20 10 mins)
Date
(7:30AM Los Angeles, 10:30AM Toronto/New York, 3:30PM London, 17:30H Moscow)
...
- Name (organization) <email>
- Troy Ronda (SecureKey) <troy.ronda@securekey.com>
- Sudesh (SecureKey)
- Filip (SecureKey)
- Firas (SecureKey)
- Talwinder (SecureKey)
- Rolson (SecureKey)
- George (SecureKey)
- Baha (SecureKey)
- Bob (SecureKey)TBD
Welcome / Introductions
Announcements
- TBDNone
Release Status
- TBDNone
Work Updates (from the previous week)
- DIDComm inbound handlers completed (Rolson)
- Selection criteria RFC (in progress) (George)
- Controller REST API first endpoint added (Sudesh)
- Legacy DIDComm envelop (in progress) (Filip)
- Restructures aries-framework-go to create two clients and services (Firas)
- State handlers (in progress for review) (Talwinder)
- DIDComm Envelope
- 50% done
Grooming
- Splitting up crypto issues - Filip / Baha (5 10 mins)
- DIDComm Envelope.
- Build wrapper for Go standard packages to match up with the Python/PHP libraries.
- #197 Legacy Encryption
- Implement RecipientKeys in CreateInvitation - Firas (10 mins)
DIDComm Envelope- Need pluggable secrets store interface & wallet interface. Also need initial simple 0.1.0 implementation. (Firas: please create GitHub items and add here.)
Design discussion
- State handlers (5 min)
- Implement RecipientKeys in CreateInvitation - Firas (10 mins)
- Next steps:
- Review wallet RFC & Python/Rust implementations.
- Create GitHub items.
- Next steps:
- State handlers - Talwinder (5 min)
- Topic: How the response is associated to the accepted invitations?
- Next steps:
- Design discussion on the primary key for a connection.
- Allow transition directly from null state to requested state.
- Believed to be minor tweak to the code.
- Merge current PR (hopefully today).
- State machine needs to execute protocol actions when performing transitions.
- Groom and create GitHub issues.
- Registration of pre/post event listeners.
- Groom and create GitHub issues.
- DIDComm Inbound Handlers[#188]/LevelDB Config[#148] - Rolson (5 min)
- Topic: Lifecycle methods for the inbound transport.
- Next steps:
- Implement.
- framework.New & framework.Close
- Underlying components will have Start/Stop
- Expect that Inbound transport is Started for framework.New
- Expect that Framework instantiates services (not Context)
- Framework is missing the lower-level non-exported bootstrap context. Needs refactoring.
- Question: should context created on each call to framework.Context()? Yes
- DIDComm protocol service package contents - George / Sudesh (10 mins)
- Topic: What is the API surface didcimm protocol & service packages.
- Model differences between the API of the various clients and the DIDComm protocols (based on the RFCs).
- Question: Where should the respective models live?
- Answer: We do not want abstractions leaking between layers. In particular, the REST API (swagger/openAPI) special models should not be part of Client nor Protocol Service.
- ReceiveInvitation should not be a special function in the Protocol Service. The functionality should be covered by Handle.
- AcceptInvitation is not a function of the Protocol Service but rather an Action on an Event fired by the Protocol Service.
- CreateInvitation is not a function of the Protocol Service but rather a static utility.
- Event messaging should use the Go idiom of channels. In Fabric SDK Go, the lower layer would create the channel and return it to the higher layer upon registration.
- Question: Where should the respective models live?
Addendum (post meeting)
- Configuration for Framework
- Rather than having the framework pass (and hold) a global configuration, we should directly inject appropriate configuration into each component.
- The configured component instances are passed into the Framework constructor.
- To make life easier for developers, we provide functional options in a defaults package that construct default packages with common options. We also envision the defaults package being able to read a configuration and construct from that configuration.
- Inbound transport
- Defaults to random port
- Exposes External Endpoint and Endpoint information
- Endpoint: The endpoint known by the transport
- External Endpoint: The endpoint reported externally
- Can be configured with a different external endpoint and configuration to set the Endpoint (e.g., host:port for HTTP transports).
- Label should be an argument for CreateInvitation
- DB storage path
- Rather than having the framework pass (and hold) a global configuration, we should directly inject appropriate configuration into each component.
Milestone progress
- TBD
Other Business
- TBD
Future Topics
...
- TBD
Action items
- TBD