Currency Module Architecture
This project could be done in three phases, each useful. This page focuses concentrates on the first phase which would enable a currency and the means to trade it and view accounts. It will also provide a directory of offers/wants, and categorise them, and transactions automatically. This would be more functional than many existing LETS schemes.
The second phase would introduce multiple currencies, and more accounting tools to cope with them. It would also bring tools and functions to make trading more robust, and suitable for larger communities.
The third phase enables communities to become indefinitely large but still usable, providing member filters and mechanisms for dependent payments.
This architecture is under review as we consider the implications of using Cyclos as the transaction engine.Phase 1
Currency module
This will set up the currency object type and create a base currency on install. The currency may be simply a group with some extra properties. In phase 2 this will have an admin screen so that several currencies can be created. Here are the kinds of functions it would have. integer newTransaction($fromId, $ToId, $amount, $description, $rate, $type, $currencyId) integer editTransaction($tId, $fromId, $ToId, $amount, $description, $rate, $type, $currencyId) integer deleteTransaction($tId) completeTransaction($tId) integer testTransaction($tId, $fromId, $ToId, $amount, $type, $currencyId) Here is the proposed currency dB table:| field | datatype | comment |
|---|---|---|
| CurrencyId | integer | First curency will always be minutes |
| Name | varchar (20) | Human currency name (another field for plurals?) |
| iconFile | filename | Some systems may represent each currency with a graphic. 32x32 png file? |
| exchangable | 1 or 0 | Non exchangable currencies will be isolated - detached from their minute value. Some currencies don't want to be valued or exchanged with other currencies. |
| value | integer | multiple of minutes |
| Min | integer | balance under which payments are blocked |
| Max | integer | balance over which payments are blocked |
| owner | accountId | the owner or owners of the currency |
| explanation | text (1000) | A paragraph explaining the purpose of the currency, and any rules or ethics associated with it. |
Accounting module
Will create a transaction table and a block for users to pay, describe, and rate transactions. It will number crunch the transaction table to produce many statistics, such as current balances and trading volumes. Finally this may need some elaborate caching, even at the database level to keep things quick and up to date. array() = showTransactions($members=array(), $filters=array(), $status, $limit) array('memberId=>'array('pendingBal', 'completedBal', 'pendingTurnover', 'completedTurnover')) = showCurrentMemberStats($members=array(), $filters=array(), limit,) //this would all be cached in the member table. Here is the proposed transaction dB table:| field | datatype | comment |
|---|---|---|
| transactionId | integer | unique ID |
| transactionType | invoice/offer/give/take | the first two require confirmation and the last will be sysadmin only. This is so the system knows who needs to complete the transaction |
| fromId | integer | the userId of the payer |
| toId | integer | the userId of the payee |
| quantity | integer | the amount of the payment |
| currencyId | integer | Transactions will be limited to one currency, for the foreseeable roadmap. |
| comment | text (200) chars | A description of the goods or services paid for |
| time | integer | the last modified time of this transaction |
| status | pending/complete/refused | |
| dependsOn | another transactionId | This is for dependent transactions, which are created and controlled by the system. |
| rating | integer 1-5 | Unsatisfactory/satisfactory/good/unbeatable |
| category | terms | It may be good have this field here rather than using a Drupal vocab, because it's easier on the database. Also it supports an idea of mine for dynamic auto-categories. |
Offers / wants
A cck contentType for users to display their skills / interests in a directory. Users will of course, only edit their own.Categorisation
Both the offers / wants, and the transactions, will be categorised automatically. Members will be tagged according to which categories they offer / want.phase 2
Use groups for multiple currencies
It will be possible for admin to create currencies. Every currency on the system will now be a group to which members sign up. Some groups may be invitation only. Members can belong to groups independently of other groups.
Currency exchange
Some currencies will be exchangable for other exchangable currencies, some may not be. Any member who belongs to more than one group will be given a currency exchange blockaccount balance limits
An addition to the accounting module, this will add maximum and minimum balances for each currency, and will veto the transaction if it puts either member outside these limits.More Accounting / visualisation
To cope with multiple currenciesFriends
This will use an existing module such as buddylist 2. Friends will live in their own block, and will see more of each other's personal information, such as address. Another exisiting module allows users to decide which fields in their profile they want to show/hide. The public will see nothing of members' details.Phase 3
PostgreSQL
If it hasn't happened already, this will be the time to open the module out to other databases. This may have good implications for caching, though that could be a lot of work.Auto payments
There will be a new kind of object - an auto-payment mechanism. This will create transactions dependent on the voluntary transactions. System and currency admins and even tithing users will set these up so that transactions or time-intervals create spin-off transactions, equivalent to demurrage, taxing, tithing, or paying membership.Member Filter functions
On a medium to large system, it will be necessary to filter, by a range of criteria, the users a user can see. This special module will be a stack of filters, tapping into several other parts of the system. The administrator will enable them and expose some of them, then the user will have an interface to apply more filters using OR. In this way the users define their own sub-communities. Rather than having all of London, I might choose to include only babysitters within five miles from me, or only my 'school' group and my 'buddies'.- trader categories (filter of calculated field)
- buyer categories (filter of calculated field)
- buddies (use buddylist 2)
- geopolitical unit (3rd line of address - filter member module)
- close (depends on finding members within given radius of me)
- groups (multiple currencies only)(depends on organic groups)
- currencies (depends on groups)