Versions Compared

Old Version 7

changes.mady.by.user Rolson Quadras

Saved on

compared with

New Version Current

changes.mady.by.user Troy Ronda

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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)
  • 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

  • Implement RecipientKeys in CreateInvitation - Firas (10 mins)
    • Next steps:
      • Review wallet RFC & Python/Rust implementations.
      • Create GitHub items.
  • 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.

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

Milestone progress

  • TBD

Other Business

  • TBD

Future Topics

...

  • TBD

Action items

  •  TBD