This draft is intended to provide developers some guidelines on how should behave a Currencies Service Provider. The acronym CSP is used in other places for other meaning, so we'll avoid it. The original draft is the result of a continuuous work from Michael Linton on http://openmoney.org
Definitions and terms
- CCS : Community Currencies Service : the System
is an application or a network of applications that provide a mutual credit community currencies administration for a given community of users.
is a group of more than 3 people that decide to share common processes of decision. We'll call it community even when it's not a communitarian group. It can be a company, a club, a family, an unformal network or whatever. About the limitation on 3, it's almost arbitrary, but it's noticeable than relationship beetween 2 or 3 people are not necessarly related to how a larger group behaves.
- Community agreement
is a set or rules that the group decided to agree for handling the interactive processes inside the group, linking each individual to the group in either a formal (writen) or unformal agreement. Unformal agreements are not advised though, as it relies on values expected to be understood by everybody and that case is not very common. Unformal agreement also name the set of agreements depending on formal agreements but not clearly stated, like when the rule "behaving gently" implicitly (culturally) means "don't insult people" or "avoid hurting people" or even "be gallant" depending the group local context and roots.
- Accounts holding
- CCS has to store securely each user balance in all currencies managed by the system.
- Transaction Recording
- the CCS records postings of numeric value exchange between account users.
- Multiple Currencies
- the system has to be able to manage multiple currencies, and their setup, configuration and use.
- User Centric
- the base element of the system is the user, and every process should be thought user-centric.
- only connects
- a reference to writings of E.M Forster - "only connect" is the primary human responsibility and opportunity.
This shows how a community of users are connected in a singular system.
This shows a section of a more extended community of users with multiple systems available.
The initial coding task is to develop an engine for the above. The perl code cc-0.1
by Richard Moore meets most of these specifications. A demo is running at http://cc.openmoney.org
and there are useful instructions
for having a worthwhile experience.
There is also a Tiki Mod called "Community Currencies
" which also seems to met most of those specifications, and with the advantade of being intetegrated within Tikiwiki CMS/Groupware. See Mod Community Currencies
for more information.
There's also a game
designed to show just how community currencies of the "mutual credit" type are fundamentally different from conventional money. Again, it really pays to read the game instructions if you want to understand what it's all about.
- is a typical account holder
- is a registry owner, a steward role in the group using the system, that has to be legitimated depending the group rules and topology.
- Community Official
- is a member of the group legitimate to take steering or group decisions according to a Community agreement.
- Technical Maintainer
- is the responsible of the technical well-being of the System at all time.
What can do a user with a CCS ?
- Apply for registration
- upon validation by a community official
- or by the system (automatic mail verification and reply-back) depending the community choice.
- Join a Currency System
- if currency is known to exist (flagged public)
- if the user is qualified to apply to that currency system (depending community agreement and also specific currency agreement)
- upon validation from steward or official or sometimes externaly choosen third party (in case of expertise required)
- Withdraw from a currency system
- cease accepting or refuse a currency
- Use a currency
- Operate a transfer to another user that accepts the currency (joined, and didn't withdraw)
- Receive a transfer from another user of that currency
- Access statistics about that currency, depending bylaws decided by the currency owner, and the technical ways available to produce stats (lists, preformatted reports, graphs, ...)
- Access own records
- personal ledgering ability of the system have to be provided with integral full-time access to all operation issued by one user. The more ways the user can access his details the more the system will be trusted (as far as security is enforced to avoid forgery, as well as privacy if it is a concern in the community agreement).
- Create and administer a currency
- grants ownership status on that currency, admin right
- name and design the currency system : set terms and conditions, sets flags like open or closed in the process for new users joining
What can an owner of a currency do?
- can approve or reject user applications if currency policy is defined that way.
- post or reverse transaction on behalf of joined users
- freeze a user's use of that currency
What can an owner of a cc registry do?
- has all privileges of all currency owners, thus can act for them
- can close a currency
- can freeze any user
... work in progress...
- upload postings
- All interaction with the System should be possible in batch mode to allow preparation of transaction sets off-line - particularly useful for retail point of sale processes for instance
This document has no legal value never, just a bunch of unformal information constantly evolving.
If an offical document ever appears it will not be here...
So, jump in and collaborate !