Minutes of the weekly meeting of the Mojaloop Design Authority 2021-01-06 13:00 UTC
- James Bush (Chair) firstname.lastname@example.org (JB)
- Miguel de Barros email@example.com (MDB)
- Simon Oriko firstname.lastname@example.org (SO)
- Sam Kummary email@example.com (SK)
- Godfrey Kutumela firstname.lastname@example.org (GK)
- Adrian Hope-Bailie email@example.com (AHB)
- Pedro Barreto firstname.lastname@example.org (PB)
- Istvan Molner email@example.com (IM)
- Justus Ortlepp firstname.lastname@example.org (JO)
- Bryan Schneider email@example.com (BS)
- Michael Richards Michael.Richards@modusbox.com (MR)
- Review Original Mojaloop Project Principles (Review Original Mojaloop Project Principles · Issue #70 · mojaloop/design-authority · GitHub) continuing discussion after feedback from TGB.
- Design for Reliable Notifications on Finalisation of a Transfer (Design for reliable notifications on finalisation of a transfer · Issue #74 · mojaloop/design-authority · GitHub). Presentation by Miguel.
- Presentation by MDB of item 2 on the agenda.
- A PR has been raised illustrating the proposed architecture. This has been reviewed by the core OSS team.
- The current notification mechanism for API callbacks was reviewed. Issues were pointed out: business logic exists in the notification handler which is not desirable and there is no retry mechanism meaning a payer DFSP may have to make additional API calls to discover the state of a transfer it has previously prepared.
- Requirements for improved mechanism were discussed:
- It was asked where the requirements had come from. MDB indicated there were some requests from the community for other notification transports other than HTTP such as gRPC, email etc…
- JB raised that that we should not design or implement things for which there is not a clear and well supported business requirement.
- Discussion ensued about the benefits of implementing desirable things cheaply while implementing other things vs the downsides of spending effort on implementing things for which there is no need, such as additional complexity.
- Additional questions from the group to MDB on details of the proposed design such as retry mechanism, topic allocation for notification messages, where various responsibilities lie within the design etc…
- A further focused discussion session was requested due to lack of time to discuss in sufficient detail at this meeting. Action on JB to arrange.
- Discussion of item 1 on the agenda - Review of Original Mojaloop Project Principles
- AHB requested an editor be assigned to own the document going forward and also that a deadline should be set for further review by the Mojaloop Technical Governance Board (TGB)
- A further focused session was requested to produce a final draft including responses to recent feedback before end of the week (for final review in the next DA meeting). Action on MR to arrange.
- AHB raised the possibility of increasing the length of the weekly DA meeting. Action on JB to adjust meeting invite.
- SK raised that discussion of Modusbox IaC contribution to the community should be postponed until next meeting due to time constraints.
- JB to arrange further discussion session on agenda item 2 for all interested parties.
- MR to arrange focused edit session on Mojaloop Project Principles document before end of week.
- JB to increase meeting length to 60 minutes.