Meeting mins summary @ [Week 1]

mediator project meeting on Friday 16 June 2023

Summary:

• Patrik Stas gave an overview of the internal structure of how the mediator service could be. DIAGRAM.2 @ Slack
• aries-vcx had implementation of mediation service (vcxagency-node).
  problems:
  • written on lib-indy (indysdk),
    it bootstrapped the ecosystem, but is not maintained any more.
  • written in node and interfaces with lib-indy using ffi
    • hard to maintain
    • performance issues
  • does not implement aries pick-up messages advantages
    • does have unique features though, like filtering by status etc.
• Explained how Rust traits are a good model for interfaces.

Goals , Considerations:

• This service should have high throughput. // This makes us want to use storage interface like DB etc so we can scale horizontally.
• Notification support is a must (can be implemented later, but design accordingly)
  • Consider websocket support in http library for mobile client notifications
• Using Rust for this, and reimplementing gives:
  • safety,
  • reliability
  • not messing around with ffi
  • good structures in rust.
  • will use standard protocol and not custom implementation of pickup.
  • Contribute pickup protocol data model back into aries-vcx

Action points (for next week):

• research http in rust (including wss support)
• Ask Miroslav Kovar about good options for HTTP server and considerations to take.
• create a skeleton http service with 3 endpoints (forward, register-mailbox, pickup)

Personal contemplation:

• open notifications (https://unifiedpush.org/)
• pondering how interfaces are like robot hands, and the core service is the brain.
  In core we model what needs to happen, the interfaces are the abstract model of action (or plug-able slots).
  Dealing with context/environment specifics, (à la physical slot-able and swappable robohands), is implementation.