Credit Commons technical implementation

The Credit commons consists of exchange groups, each of which has its own unit of account, used for converting members' units.

The groups can be nested recursively, allowing massive scale.

Transactions between groups must be written on the ledgers of all groups and all their parents up to the common parent.

Political requirements

The Credit Commons is comprised of similar applications each which serves one group, and should be hosted independently by their groups. The application would have two db tables.

Account 0 would be special - able to do atomic transactions with the parent group.
Account 1 would belong to the administrator.
Each application should be addressible by all its members, so if it's not a permanment script on a blockchain, it needs to update its children.

Internal operations

Each application should provide the following functionality to its members, independent of other instances.

Essential

Expected

Desirable

Networked operations

These operations constitute the essence of the Credit Commons, which is a protocol for connecting autonomous groups. Every account has a full address starting 'World' (which is implicit) /timebanks/France/Bonheur/name or number. Addresses can be relative, thus, in order to pay from one timebank in UK to one in France, the recipient address need only be France/bonheur/99 Not yet decided how to edit transactions accross ledgers. Leave till later

It is not a problem if writing to more ledgers incurs more transaction fees.
It is not a problem if there isn't immediate consistency.

API Requests

NB A convention is needed about whether quantities are given in sender or receiver units, parent or child units.

Child to parent

One group asks to join another (as a child to parent).
POST: name (string) exchange rate (float)
Response: OK or error.

Request to disconnect (N.B. balance of zero account must be 0)
DELETE: name(string)
Response: OK or error

Request authorisation for a transaction.
POST: 2nd party address (string), quantity (float), description (string)
Response: OK, meaning it is written, or an error code and details.

Parent to child

Update balance limits (also used to accept membership)
PUT: max (float),min(float)
Response: OK

Request authorisation for a transaction.
POST: 1st party group(string) 2nd party address (string), quantity (float), description (string)
Response: OK, meaning it is written, or an error code and details.

Orphan notice (account balance must be 0)
DELETE: zero
Response: OK or not OK

Notifications, balance warnings, Approval requests
POST: Message code, variables
Response: OK