Minutes of the weekly meeting of the Mojaloop Design Authority 2021-09-08 10:00 UTC
- James Bush (Chair) email@example.com (JB)
- Sam Kummary firstname.lastname@example.org (SK)
- Simeon Oriko email@example.com (SO)
- Miguel de Barros firstname.lastname@example.org (MDB)
- Paul Baker email@example.com (PBK)
- Justus Ortlepp firstname.lastname@example.org (JO)
- Istvan Molnar email@example.com (IM)
- Comments on previous minutes
- ModusBox to present early design thinking on Reporting and Auditing bounded context within the scope of BizOps framework workstream.
- Quoting and Transfer Services do not use apply Canonical JSON transformation as part of the Duplicate Check logic (https://github.com/mojaloop/design-authority-project/issues/83)
- No issues with previous minutes were raised
- PBK presented early design thinking for Reporting and Auditing bounded context implementation happening within BizOps framework workstream.
- Convening feedback indicated a desire from mojaloop operators to trace transfers through a switch
- Bounded context exists within reference architecture “Reporting and Auditing” this appears to be the most logical place for this functionality to live
- BizOps work needs to be compatible with current mojaloop implementation and also possible enhancements
- Design features event subscription which at present would use kafka but could use any event stream in future.
- Design processes events and creates a read-only reporting database from them
- GraphQL highlighted as query language interface to reporting data stores.
- UI is not a focus of the current funded work; which is limited to API capability.
- All present agreed that the design appeared to meet both current and future envisaged use cases well.
- MDB raised DA issue #83 for discussion (Quoting and Transfer Services do not use apply Canonical JSON transformation as part of the Duplicate Check logic)
- Reordering of JSON keys may cause a duplicate to not be detected and thus passed into the core for processing with unintended consequences.
- RFC8785 exists to specify a potential mechanism for preventing this.
- MBD asked the group for comment
- JB agreed that this is necessary but doing a timestamp comparison on every request is undesirable for performance reasons. Further thinking is warranted to see if there are better alternative mechanisms for not impacting existing datasets.
- JB suggested to circulate the issue on DA slack channels and seek input from wider group
- JO asked what impact would be on an FRM, MDB clarified no impact.
- MDB to circulate DA issue #83 on DA slack channels and seek inputs from wider group