[Webinar Proposal] Mutual Credit / REA Accounting

@Oli SB The name "OpenMoney API" is misleading. This is simply a software component that provides an API through which to interact with a database (currently implemented using Couchbase). The API constrains what can be written to or read from that database, by whom, and under what conditions. Specifically, it allows for the creation or removal of enclosures ("namespaces"), users ("stewards") and scalar records ("accounts") or scalar values ("currencies"); the enclosure of namespaces within namespaces (therefore recursively), and the enclosure of stewards and currencies within namespaces; the relocation of such "objects" from one namespace to another; the simultaneous and equal adjustment of the value recorded in two metrically-/dimensionally-equivalent accounts (i.e. using the same currency). In the special case of a currency representing a money type, we're used to calling this a payment; therefore the term payment is used for all such simultaneous adjustments. This is the only purpose of this component, but as such it provides an arbitrarily expanding set of what in the special case of a money might be called a payment channel - a pipe with a number at each end - but what makes it a payment is what the users choose to do with these numbers (each in its own account), and that is a matter of protocol - a human protocol.

The namespaces (enclosures) provide a variety management mechanism, and therefore the potential to separate modalities of interaction. I don't have time to go into that in detail, but some notes I wrote with Trevor Hilder in 2016/2017 (https://www.lrc.org.uk/files/TH_JW_Insights_From_Cybernetics_2017-04-14.pdf) will go some way to explaining the why putting everything into one huge collection of interconnecting buckets, equating anything to anything else in terms of "value" leads inevitably to the formation of conditioned hierarchies at the expense of of other modalities - especially unconditional care and learning networks. (NB, that "paper" had to be written in a hurry under rather difficult circumstances, and the 8000 word limit was a severe constraint. Expansion upon the points raised here remains very much a collection of works in progress. It should also be noted that at the time this was written I hadn't yet realized that the OM recursively-nested "namespaces" proposed by Michael are essentially isomorphic to the type of structures I'd been thinking about for a while, but, like many people, I had difficulty breaking through this particular language barrier to identify the synergy.)

Getting back to the OM software ...

The "OpenMoney network" component is a proof-of-concept user interface, usable (with some help and guidance) to demonstrate a concept ("open money" - note the use of two words in lower case letters). It was written very quickly by a skilled programmer with very limited time, so some bugs still remain and it lacks the built-in help system it really needs.

The "OpenMoney network" interacts with the "OpenMoney API" using familiar protocols - HTTP, SSL, Oauth2, TCP/IP, etc. - nested (or "stacked") as such protocols always are. The "human protocols" are another layer in a "protocol stack". The decoupling of these components means that all manner of alternative components, including much flashier user interfaces, can be added in due course. It also means that alternative implementations can be built on the other side of the API - for example using Holochain, an option consistent with the OM objective of placing responsibility for, and control of, data in the hands of its "owner" while also offering other advantages at scale. It also means that the API itself can be expanded functionally as and when useful. The API is both a transducer and a variety attenuator.

The "OpenMoney Gift API" is a variant with its own proof-of-concept/demonstration client - "OpenMoney Gift" - designed specifically to demonstrate concepts of "covestment", a special case of open money in which feedback loops between altruistic bodies, humans and locally-enclosed trade components create a pump mechanism. ("OpenMoney Gift" could have been designed to work with "OpenMoney API" rather than "OpenMoney Gift API", the latter perhaps having been designed as a temporary step.)

To describe this as "simply another 'ledger'" is simply wrong. Users are called "stewards" because each holds responsibility for her/his/its own collections of namespaces, accounts and even currencies - within the bounds of name-collision) - and can create, manage and destroy these to the extent allowed by whatever rules (protocols) are imposed at a meta-level.

Open money is a special case of open metrics, a domain within a domain. Open metrics encloses everything we can measure (even rather fuzzy measures such as satisfaction, happiness, eudemony, ...) as well as compound/vector measures relating to the physical world, while open money encloses everything we can control.

The idea of using the OM system to provide a gateway between other enclosures - especially using exchange mechanisms - makes no sense in the OM framework. Any "money" that can be equated to another "money" through an exchange mechanism immediately opens both up to commodification and speculation - the money become a commodity in its own right rather than simply a representation of things, it enables (and even requires) the externalization of SEP ("Somebody Else's Problem", to use Douglas Adams's term) in the form of uncontrolled extraction of non-renewable resources, uncontrolled destruction and toxification of our shared natural resources, slavery, and all the reinforcing loops which drive us towards global destruction. Just because Elinor Ostrom can show us ways to mitigate the Tragedy of the Commons given the right conditions, that doesn't mean that we currently have any agreed approach to work at even national or regional scale, far less at global scale. The limits to what we afford (collectively, globally) are set by the planet itself and the energy received externally. Our needs, as humans and as life more generally, have a lower bound - and Manfred Max-Neef and his colleagues, as well as Maslow and others, cast light here. Bridging the gap between these upper and lower bounds is, in essence, a mutidimensional control problem - and finding a compromise between the "needs" of humans and those of lifekind more widely, makes this also a problem in optimal control. This is where Mick Ashby's work on "ethical regulators", helps to shine a light on how to bridge the gap between the multivariable control problem (very much the domain of Ross Ashby and Roger Conant in the Good Regulator Theorem). But I digress ...

Any money which is isomorphic to legal tender will ultimately be part of the problem, even if it can be tweaked to provide narrowly-useful remedial solutions.

Comparing OM and one-type-fits-all currencies/monies (such as legal tender, OCN, credit commons, Ripple/Trustlines, etc.) makes no sense. The objectives are deeply and fundamentally different.

Don't take this as a re-interpretation of Michael's ideas. Michael expresses his thoughts in his own way - as we each should, negotiating a shared language as needed, and depending on the who and whom and context in any particular conversation. What I've written above reflects my own perspective, and touches upon the points of synergy I have established with Michael's approach. Michael's perspective will be different on many points because because we have converged here along very different paths, driven by different sets or configurations of concerns, but I have have found far more synergy here than elsewhere.