LETSlink UK
Community eXchange Software Service
Some systems will have one currency only, while others will have currencies created at will by any member. Time will tell the best models for currencies but for now we need to be as flexible as possible.
*the nominal value in minutes is a way of making a currency exchangable in principle with other currencies, which is very important to Mary. There is another currency property, 'whether or not it can be exchanged for other currencies' that determines its practical value. The nominal value in minutes also helps to account. You can assess member's 'total' balance only with reference to a common yardstick, which is important if the system needs to see who's pulling their weight. John suggests energy is more universal and he might be right. Trouble is, energy is hard to measure, especially mental energy and embodied energy.
John W Says: Hard limits may not be enough for all purposes. It may turn out that some systems designs may require support for a mechanism to allow the "resistance" to increase proportionally to commitment (analogously to a spring) or to have a leakage rate proportional to the absolute value of the member's account balance. An example is the LEG system I designed for exchange (but most definitely _not_ store-of-value) among SMEs and sole-traders, in which the an account leaks towards zero (if the balance is > 0) and towards minus infinity (if the balance is < 0).
Matthew says John, in my understanding these interesting mechanisms all consititute unusual autopayment modules. You keep stressing the need not to define what a currency is, but we need some definition if this system is ever to be built, surely.
Auto-payment mechanisms
You're probably quite right, Matthew, in categorizing mechanization of the LEG "leakage functions" as "unusual autopayment modules". I just introduced this as an example to illustrate the need for flexibility (particularly since I don't yet know how flexible these might need to be).
Currency definition
Perhaps I haven't expressed my meaning clearly. It certainly wasn't my intention to "keep stressing the need not to define what a currency is" but rather to stress the need to avoid unnecessary constraints on the characteristics defining a particular currency.
In particular I want to make sure that all currencyies are not constrained to a particular value system.
The very first bullet point above states: "A currency will have the following properties: nominal value in minutes", and that is exactly the sort of prescriptive definition I would like to avoid.
It certainly makes sense to use time as the measure for certain types of currency (particularly those involving human activity and the allocation of time-shared resources), but for store-of-value systems a more fundamental unit for many purposes would be energy (kWh, Joules, GeV, Ergs, etc.) and for stable exchange currencies at the very local level, a more fundamental measure might be that of staple food (as the price loaf of bread was in the past - or as the price of an omelette is, or at least was, the standard by which to compare the relative prices across the menus in French eating places).
So all I'm really urging is that no constraints be built into the LoCuS specification that would more properly be built into the specification of a particular (currency) system type definition (such as LETSystem, TimeBank, timeLETS) which would provide a "configuration definition".
John :)