We want to build a payments ecosystem so that community currency entrepreneurs can pick up appropriate components and make them work together quickly thus concentrating their resources on developing their Unique Sales Proposition. We want marketplace entrepreneurs and community currencies to be able to choose between Ripple, OpenMoney, and Cyclos for their transaction storage, and to know that these choices will not prevent them from intertrading. They need to be able to re-use existing mobile payments apps rather than write their own. They need to work with different identity servers, such as open ID or maybe just a Bitcoin wallet address.
There are many packages available each of which emphasises different functions, but there is absolutely no interoperability yet. This means entrepreneurs are forced to start with one package, usually Cyclos which small projects find difficult to work with, and build the rest from scratch. So let us first identify the main functions of the systems we want to support.
Functions
- Identity management
- Users need to authenticate before they can authorise transactions using their wallets. One user may have multiple wallets. So the user profiles and their wallets need to be in one system which knows where they are logged in from.
- Accounting
- The accounting system stores, primarily a log of transactions between accounts or wallets. Transactions should have a currency id. No user identity information is needed. The system needs to write transactions and read transactions and aggregate transaction data. Mysql could do this, but there are better options. Ideally the database would be distributed, so it could be very available and fast and resilient.
- Marketplace
- Users list their offers and sometimes wants in public or closed space. There may be rating systems, prices, expiry dates, discounts here.
- Payment
- A system for one user to register a payment with another user. It presents the user with a form, tries a payment, and gives the user feedback. Sometime a payment system will work between systems, for example checking with both users' banks, and sometimes a system can authorise payments itself. The payment might come through a web form, or a mobile phone app, or an SMS, or NFC device. The payment will need to be validated by the business logic before being written to the database
- User Interface
- There is usually 'main' platform or framework where all the other features are programmed, and which everything else must connect to. Examples are Drupal, Odoo, LifeRay.
Business Logic
The glue that joins all of these together is business logic, which is concerned with who can trade with whom in what currency and when.
We need to be able to define rules like this:
"Show this discount to that user if their balance is above 100 and they have bought bananas in the last 3 months."
Business logic determines the min and max limits on the accounts, according to account types, or wallet types, or transaction types. It determines which transactions are visible to which users. It determines transaction workflow and multisignature transactions. It may also deal with rebates, and escrow. Viewed as a function this element is problematic because it could depend on any detail anywhere in the wider system. It presents another problem because every existing system already contains elements of business logic in its configuration.
So considering these components, I would like to suggest where the APIs need to be defined. We can start with simple APIs and them extend them later to cope with richer business logic. So far, I see the need for about 4 APIS.
The simplest API belongs to the transaction engine. It takes instructions to save, update and display transaction data denominated in many currencies, of course. Cyclos and my Community Accounting Drupal module each have a REST API for this.
The identity system also receives instructions from the user interface for attempted logins, then it reports to the rest of the system who is logged in and any other info it stores about them.
The payment form needs API so that it can be prepopulated, usually by the marketplace.
Nothing interrogates the marketplace so no APi is needed unless reputation is stored there. perhaps that is a reason to store reputation with identity. A grey area for now.
So it looks like we need to start by designing, or preferably identifying 3 APIs, for the transaction engine, identity server and payment form/device.
Written with help from Lucas Huber. See Jemma and CC-Hub for more of his work.
Comments