...
Planned topics
- Work updates (10 5 mins)
- Grooming (30 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)
...
- 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
- 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
...