Mojaloop Community Central: Michael Richards

ISO 20022 Document Repository

Michael Richards — Thu, 15 Feb 2024 17:17:31 +0000

We have now created a GitHub repository to store the documents and other materials we are creating in support of our mission to make the ISO 20022 standard better aligned with the Level One Project's goals. Feel free to browse the documents and raise issues; or contact me either directly or via the ccb-sig-iso20022 channel on the Mojaloop Slack. Enjoy!

Settlement API SIG meeting

Michael Richards — Thu, 15 Feb 2024 15:53:11 +0000

This is to inform all community members that the Settlement API Special Interest Group, convened by Jason Brouwer, will be holding a meeting from 12:00-13:00 UTC next Tuesday, February 20th.

The purpose of the meeting is to discuss the draft Swagger definition of the API, and the review of it against the proposed Settlement Administration user stories. We shall then look to work towards a finally agreed version of the API which we can take forward to implementation.

If you would like to attend this meeting, please contact me and I will be happy to add you to the invitation. If you are unable to attend, we shall be recording the meeting and a transcript will be posted to the ml-settlements-v3 channel on the Mojaloop Slack.

DA Meeting minutes 2023-12-06

Michael Richards — Wed, 06 Dec 2023 10:08:16 +0000

Minutes of DA Meeting 2023-12-065

Attendees:

Paul Baker paul.baker@infitx.com (PB)
Jason Bruwer jason.bruwer@coil.com (JB)
James Bush jbush@mojaloop.io (JB)
Karim Jindani karim.jindani@paysyslabs.com (KJ)
Vijay Kumar Vijay.Kumar@infitx.com (VK)
Sam Kummary skummary@mojaloop.io (SK)
Paul Makin pmakin@mojaloop.io (PM)
Simeon Oriko simeonoriko@gmail.com (SO)
Michael Richards Michael.Richards@infitx.com (MR) (Chair)

Apologies:

Absent:

Aung Thaw Aye AungThaw.Aye@thitsaworks.com AT

Agenda:

Report on actions from last meeting
- Post the DA charter somewhere public
Transition (SO)
vNext NFRs (JB)
AOB

Minutes

Actions from previous meeting
- Post the DA charter somewhere public
- Will be on docs.mojaloop.io (SO)
- Da charter up for review by community in January
Transitioning (SO)
- Congratulations to newly elected members
- Welcome to Karim and Vijay
- MR has served as chair for 2 years. Received the applause of a grateful public. DA needs to elect a chair.
- New system: DA will have co-chairs, 1 from MLF, 1 from community. Community co-chair is senior.
- Co-chair from MLF is JB.
- Elected members can stand, all members can vote.
- MR disqualified by charter from standing again. Eligible: Aung, Karim, Vijay, Paul Baker.
vNext NFRs (JB)
- Product council call discussed road to release candidate for Baobab.
- Assessment process for vNext will kick off as soon as beta is available.
- Process is to compare beta against existing codebase in terms of functionality, but also NFRs.
- Call for assistance.
- PB: What is required? JB: should be simple. Replication of databases, resilience, redundancy.
- Could be research-driven. Is best practice being followed?
- We're assessing the code that's been delivered.
- Kafka is the same in both; new codebase has Mongo instead of Kafka.
- MR: event-driven nature of vNext may require new NFRs.
- Must avoid negative framing: MUST rather than MUST NOT.
- SK: could we look at an example? JB: replication of data in a database. vNow can use synchronous replication in production (MySql 8) so writes are guaranteed to have been persisted on a quorum of targets before success is reported.
- Are there single points of failure? We should have other instances of every service.
- System should be able to continue processing even if components are in a degraded state. Does this have to be answered in the same way in both systems?
- MR: is there a relationship with the invariants? JB: yes, but there are some NFRs missing from them. We should review.
- PB: interested , but worried about time... JB: will send links to documents and ask for review, invite to call to discuss issues. Interested: VK
AOB
- VK: documentation? MR: SO will publish charter, and there is an issues list. MR to publish.

Actions:

JB: store the invariants document in GitHub in MarkDown
MR: publish link to GitHub issues

DA Agenda 6 December

Michael Richards — Wed, 06 Dec 2023 08:53:10 +0000

DA Meeting 6 December 2023

Agenda:

Report on actions from last meeting
- Post the DA charter somewhere public
Transition (SO)
vNext NFRs (JB)
AOB

Minutes of DA Meeting 25-10-2023

Michael Richards — Wed, 25 Oct 2023 10:06:52 +0000

Minutes of DA Meeting 2023-10-25

Attendees:

Paul Baker paul.baker@infitx.com (PB)
Miguel de Barros miguel.debarros@infitx.com (MdB)
James Bush jbush@mojaloop.io (JB)
Johann Foley johannes.foley@sybrin.com (JF)
Sam Kummary skummary@mojaloop.io (SK)
Paul Makin pmakin@mojaloop.io (PM)
Michael Richards Michael.Richards@infitx.com (MR) (Chair)
Jane Stroucken Jane.Stroucken@infitx.com (JS)

Apologies:

Pedro Barreto pedrob@crosslaketech.com (PSB)
Jason Bruwer jason.bruwer@coil.com (JB)
Tom Daly tdaly61@gmail.com (TD)
Godfrey Kutumela godfreyk@crosslaketech.com (GK)

Absent:

Aung Thaw Aye AungThaw.Aye@thitsaworks.com AT
Greg McCormick greg@frms.io (GM)
Simeon Oriko simeonoriko@gmail.com (SO)
Justus Ortlepp justus.ortlepp@gmail.com (JO)

Agenda:

Report on actions from last meeting
- Post the DA charter somewhere public
Issue 70: Review of Mojaloop invariants (JB)
DA involvement in API changes (PSB)
AOB

Minutes

Actions from previous meeting
- Post the DA charter somewhere public
- Still open
Mojaloop invariants
- Document discussed and actions agreed
DA involvement in API changes (PSB)
- Agreed that there needs to be some kind of formalisation of the relationship.
- TBD what this should be.
AOB
- Thanks given to MdB from all present for his outstanding contributions to the DA over many years. Good wishes and success expressed for his new job.

Actions:

JB: store the invariants document in GitHub in MarkDown
JB: create a shareable version of the document that people can comment on.

DA Meeting 25-10-2023

Michael Richards — Wed, 25 Oct 2023 08:36:00 +0000

DA Meeting 25 October 2023

Agenda:

Report on actions from last meeting
- Post the DA charter somewhere public
Issue 70: Review of Mojaloop invariants (JB)
DA involvement in API changes (PSB)
AOB

Agenda for DA meeting 2023-10-11

Michael Richards — Wed, 11 Oct 2023 08:15:24 +0000

DA Meeting 11 October 2023

Agenda:

Report on actions from last meeting
- Post the DA charter somewhere public
- SK: liaise with performance workstream to review tasks for donation.
Issue 70: Review of Mojaloop invariants (JB)
Adding security to the DA charter (TD)
Issue 107: Mojaloop security review (TD)
Issue 108: Design and strategy questions (TD)
DA involvement in API changes (PSB)
AOB

Minutes of DA Meeting 2023-10-04

Michael Richards — Wed, 04 Oct 2023 10:26:56 +0000

Minutes of DA Meeting 2023-10-04

Attendees:

Paul Baker paul.baker@infitx.com (PB)
Pedro Barreto pedrob@crosslaketech.com (PSB)
James Bush jbush@mojaloop.io (JB)
Tom Daly tdaly61@gmail.com (TD)
Johann Foley johannes.foley@sybrin.com (JF)
Sam Kummary skummary@mojaloop.io (SK)
Simeon Oriko simeonoriko@gmail.com (SO)
Michael Richards Michael.Richards@infitx.com (MR) (Chair)

Apologies:

Miguel de Barros miguel.debarros@infitx.com (MdB)
Jason Bruwer jason.bruwer@coil.com (JB)
Godfrey Kutumela godfreyk@crosslaketech.com (GK)
Paul Makin pmakin@mojaloop.io (PM)
Jane Stroucken Jane.Stroucken@infitx.com (JS)

Absent:

Aung Thaw Aye AungThaw.Aye@thitsaworks.com AT
Greg McCormick greg@frms.io (GM)
Justus Ortlepp justus.ortlepp@gmail.com (JO)

Agenda:

Report on actions from last meeting
- Where are we on currency conversion?
- Post the DA charter somewhere public
Position handler batching (VK)
Adding security to the DA charter (TD)
Issue 107: Mojaloop security review (TD)
Issue 108: Design and strategy questions (TD)
DA involvement in API changes (PSB)
AOB

Minutes

Actions from previous meeting
- Where are we on currency conversion?
- OK to proceed with PoC.
- We will revisit improvements starting at the convening
- Post the DA charter somewhere public
- Still open
Position handler batching
- Link to documentation
- PB: there was batching, but it didn't work.
- VK picked this up and designed it.
- Some initial test results
- VK: existing batching only for prepare handler, this change applies to all messages
- Kafka consumes a fixed number of messages, selected by participant currency ID
- Processing speed depends on batch size: 1 op/sec start position; 100 ops/sec with batches of 10; 1000 ops/sec with batches of 100.
- Performance on a single machine with position handler only.
- One handler per account ID.
- PSB: can we get a deadlock? VK: no. Each handler will deal with a separate account, there should be no competitive locks.
- JB: if lock at the point of reading the balance then you could have multiple processors processing the same account.
- SK: we are using Kafka to partition.
- PSB: how do you assign where the fulfil has two accounts? SK: we don't have to do that. In fulfil, we only update the creditor account. In step 1, payer account subtracts from the position. In fulfil, payee account gets credited.
- PSB: how do we assign messages to bins? PB: all actions are assigned to bins automatically
- PSB: how do we manage technical failures?
- JB: this doesn't work around the presence of a single account balance. PB: the results are so good that it's not a problem.
- PSB: this is scale up, not scale out. PB: yes, we need to do a full test. VK: we did try scaling out to several instances on one node. Improvement was preserved.
- PSB: how do you commit to Kafka when it fails? VK: another handler picks it up. PSB: that's not a good strategy, because it gets the batch again. You need something like a dead letter queue. PB: it processes the failure, then commits the message. VK: if there is batch level failure, then we don't commit the messages. JB: you can't choose which messages to process. PSB: you have to assume that you can only process the whole batch.
- JB: also a resilience thing - you need a backup strategy if a process dies. VK: Kafka will manage that itself.
- PSB: this is what we've done in vNext. If done well, it's great.
- TD: how do we do full-scale performance tests? Why do we need to improve performance on vNow? JB: INFITX have a business case that they need to meet. TD: seems to trivialise the TGB statement that performance was sufficient.
- Foley: in principle it all makes sense. How do we handle errors? We think that's OK, but we need to be sure. Opinion: would be great to see an E2E performance test with real circumstances and make a decision based on that.
- PSB: So, we make PoC decisions based on the agreement that the performance is good enough, then we have a business need to improve performance for the PoCs? Were Infitx not part of the ones that said vNow's performance is enough?
- SK: “We” who? Who said performance is good enough of which version ? Sorry it isn’t clear
Adding security to the DA charter (TD)
Issue 107: Mojaloop security review (TD)
Issue 108: Design and strategy questions (TD)
DA involvement in API changes (PSB)
AOB

Actions:

SK: liaise with performance workstream to review tasks for donation.

DA Agenda 2023-10-04

Michael Richards — Wed, 04 Oct 2023 08:57:36 +0000

DA Meeting 4 October 2023

Agenda:

Report on actions from last meeting
- Where are we on currency conversion?
- Post the DA charter somewhere public
Position handler batching (VK)
Adding security to the DA charter (TD)
Issue 107: Mojaloop security review (TD)
Issue 108: Design and strategy questions (TD)
DA involvement in API changes (PSB)
AOB

DA Agenda 2023-09-13

Michael Richards — Tue, 12 Sep 2023 17:22:42 +0000

DA Meeting 13 September 2023

Agenda:

Review: core changes to support currency conversion (MR)
DA involvement in architectural security (TD)
DA involvement in code reviews (MR)
DA involvement in API changes (PSB)
AOB

Implementing FX improvements in PI 22

Michael Richards — Fri, 08 Sep 2023 17:26:41 +0000

Currency conversion workstream

PI 22 implementation

Those of you who were present, either in person or virtually, at the last convening in Kigali will recall that I presented on the current state of the currency conversion (FX) workstream. At that convening, I presented a version of currency conversion which is substantively the same as what we are now proposing to implement. Our current proposal may differ in some points of detail, as might be expected as a consequence of the more detailed analysis and discussion in which we have engaged over the course of this PI.

The commitment that we made at the Kigali convening was to implement an initial version of the FX API, as currently proposed at that time, at the end of this PI. This is still my objective. There were, as I recall, no dissenting voices at that time.

Since this is the case, I'm afraid that I will reluctantly have to exclude from future discussions of the implementation any suggestions which do not have to do with the unworkability of the solution currently proposed, and which are not supported by evidence.

It is almost certain that the design currently proposed is not the best that could possibly exist, and completely certain that it could have been improved over the course of its development by greater participation from the community. However, we now have a design which has been agreed by the community at the PI Community Meeting, and I intend to implement it.

It is entirely possible that those of us who have worked long and hard on this design have nevertheless missed some crucial element which would render the implementation useless. Any comments and criticisms relating to issues of that kind will continue to be welcomed with the open arms that I hope we have shown up to now. However, apart from such critical issues, the design is now closed for any improvements which would delay its implementation.

Pedro asked the question in this morning's meeting: is it not possible to improve this design? My answer is: it's always possible to improve a design, and we will start up a forum in which we can discuss such improvements ad lib. This will, I am confident, result in greatly improved versions of the FX API in the future. As I say, we shall also continue to solicit the most abrasive and robust criticism of the design and implementation from the perspectives of security, reliability and efficiency. But for now, and in the absence of such criticisms, we will work with the design we have.

If you have any comments on any matters raised by this post, please feel free to add them as comments to this document or in the Slack channel. I should say, however, that I do not propose to devote any time at Tuesday's meeting to discussion of the issues raised in this document.

Currency conversion support

Michael Richards — Fri, 08 Sep 2023 15:18:43 +0000

Planning meeting

We will hold the next planning meeting for the implementation phase of the FX (Foreign Exchange) workstream from 08:00 to 10:00 UTC on Tuesday, September 12th. The meeting will cover the following areas:

Project roles
- Product Owner - Michael Richards
- Program Manager
- Engineering manager
- Story author
Initial story breakdown

Our intention is to have implementable stories in place for a development sprint starting on Monday, September 19th.

Anyone who wants to attend this meeting is most welcome. Project documentation is here.

If anyone has any questions, please don't hesitate to get in touch