-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review Original Mojaloop Project Principles #70
Comments
This is the invariants question. Leave open. |
Mojaloop InvariantsThe following invariants have been established during the course of the platform’s development and based upon the technical requirements inferred from the Level One Project Principles (※a)
Design Decisions
Annexure A : Level One Principles OverviewThe Level One Project proposes a new low-cost payments system that supports inclusive, interoperable digital payments. The Level One Project Guide outlines a vision of how an inclusive digital financial services system can work for the benefit of poor people. The underlying design principles of the Guide include:
By utilizing an open, digital approach to transactions, and partnering with organizations across the public and private sectors, the Level One Project aims to provide access to a robust, low-cost shared digital financial services infrastructure, sparking innovation from new and existing participants, reducing risk, and generating substantial value for providers, individuals and economies in developing markets. Additional resources have been created to help governments, NGOs and financial service providers successfully implement these changes. Editorial Notes※aIf we don't capture the rationale, the reason why these principles are important, future generations of Mojaloopers will not understand the context that drove the selection of the principles and might happily discard without appreciating the potential impact. Noted — we will re-open this and provide additional context as suggested. agreed - that was the intention of the comments I gave (which I am not sure were fully answered with the responses/changes - there wasn't enough of the why to make it sufficiently useful to outsiders. great that we're re-opening. and happy to review again through a product lens (as fundamentally some of these should form the core of our messaging/positioning to adopters) ※dWould add to be the authoritative system of accounting record covered in #3, is that sufficient? no, it's a primary function ※gNon-repudiabile? We need to tie back to some of the high level principles Covered in #10 - security not actually covered in #10 - and needs to be understood in the context of deterministic behaviour ※jneed to explain why necessary to achieve non-repudiation Added additional description text around general confidentiality, integrity and non-repudiation Agreed, this is about high throughput concurrency and accuracy not pure speed and latency. And the constraint should be recorded somewhere - it goes something like this- the switch would never allow a participant to exceed their position cap on the collateral made available to the system The records need to explain the deterministic manner any decisions were arrived and have the accounting records that show both successful, declined transfer request and errors Necessary for complete record and dispute Management |
Converted the Invariants to a draft in Markdown format. I've captured the inline comments, but they should be reviewed and deleted after we've processed them. This document should now be placed under version control in the appropriate repo where we can party on it with full Git. |
@bushjames @elnyry-sam-k @PaulMakinMojaloop — Let's progress this... |
Many thanks for this @millerabel . |
Please see PR against the mojaloop documentation repository adding the invariants to technical docs: mojaloop/documentation#428 |
All community members wishing to commend on the PR before it is merged should do so immediately. Note that there are additions and updates that should be carefully reviewed by interested parties. The DA will be asked to vote to accept the contents of the PR as the Mojaloop Invariants. |
Approved from my side. Thanks James. |
One Line Summary:
The design and development of Mojaloop was based on a set of principles which were never properly documented and communicated and as part of this initiative, the DA will review the provided list of principles from the TGB and provide feedback before releasing to the open community for only additions and corrections no detailed review is needed.
Request Details:
The TGB seeks to ensure that the project principles are known and adhered to by the broader community starting with the DA and to this effect, the DA will take a first step in reviewing the principles and handshake feedback with the TBG and therefore the principles will be broadly communicated to the community. Below is a summary of the principles :
Core Principles:
• Clear in real-time, settle by end of day
• Full automatic pass-through processing
• No manual reconciliation — protocol guarantees determinism automatically
• No repudiation of transactions by facilitators
• Separate the transaction logic and use cases from the policy-free transfer of money
• Hub doesn’t parse or act on transaction details
• Simplify money transfer semantics and standardize them
• Internet-based API service hub is not a “message switch”
• Asynchronous processing to optimize responsiveness and throughput
• Hub may serve as proxy to simplify interconnection, without parsing or storing messages.
Performance Targets
• Baseline deployed system supports 1,000 FTPS, sustained for one hour, with not more than 1% of transfers exceeding 1 sec through the hub. And lower unit cost to scale than to initially provision.
• Use nodejs microservices architecture
• Implement a hash time lock of transactions details using the Interledger Protocol in Universal Mode
Artifacts:
Dependencies:
Accountability:
Decision(s):
Outstanding
Details
Follow-up:
TBD
TBD
The text was updated successfully, but these errors were encountered: