The term openmoney refers to any software supporting open money. The following is a minimal specification of the way in which any such software should operate.
The openmoney component is not intended to be complete and self-contained. Metasystemic components, whether technological, social or organizational, are required for any such tools to operate. Adaptive, resilient, co-evolving systems necessarily involve layers and appropriate extensions, with structure reviewed continually. The openmoney component is intended only to provide a recursively-nested ledger structure for REA accounting upon which much richer structures can be built.
Note: There is no obvious natural sequence in which the terms in this section can be defined. Most terms refer forward or backward to other terms within the section.
Pronouns: Since a user may be a person or an organization, or possibly a machine, the gender-neutral it and its are used below.
A registered user of any openmoney software can be any person or organization of persons that recognizes and accepts responsibility for:
To use open money is to mind your own business.
When registering, a user may optionally provide an email address and choose its notification settings. These can be update updated subsequently.
A user uses its username and private key to authenticate. The private key used to sign an authorization request which is then sent to the API along with either the username or a registered alias (secondary identity) associated with a particular namespace (in the format "name@namepace").
Once registered, a user may join any number of namespaces (subject to the permission if those namespaces' stewards) under any name (secondary identity) not already in use within that namespace. Such secondary identities all point back to the user's unique primary identity within the same registry namespace.
A user may also have any number of secondary identities in any permitted/accessible namespace lying within different registry namespaces if the implementation allows for inter-registry authentication.
Within a (parent) namespace a user is authorized only to create names (namespaces, currencies and accounts), of which it is the steward, and these persist only as long as authorized by the stewards (governors) of the (parent) namespace.
This section refers only to namespaces enclosed within the same registry namespace.
A namespace is an enclosure.
Each namespace is identified by a string divided into substrings (namespace names, in each case a lower case letter followed by a string of arbitrary length containing any combinatation of lower case letters, digits, "_" or "-") separated by the character ".". Therefore, with the exception of the root namespace, each namespace comprises at least two parts - child.parent - where the latter identified by its full ancestry "path" back to the root namespace) and is therefore globally unique [note 1]. For example, the following examples represent two different namespaces:
where both have the same namespace name at the start of the string but each has a different parent namespace.
Every steward of a namespace has the ability to close child namespaces, currencies or accounts in their namespace and then create their continuations (namespaces, currencies or accounts having exactly the same properties and values) in another (accessible) namespace. This is, in effect, equivalent to moving these safely in a way which does not lead to confusing inconsistencies in the journal entries.
A namespace can be public or private:
Any registry namespace can be enclosed within any namepace embedded within another registry namespace.
For example, a namespace identified by the string newtown.powys.wales (where wales is the root namespace of the registry in which it is defined) can be embedded into an existing namespace uk.europe.earth in a separate registry (subject to the permission of the governing stewards of that registry, and only if the enclosing namespace identified by wales has not already been placed there from within a different registry namespace). In this case, the namespace identified by newtown.powys.wales could now also be identified by the string newtown.powys.wales.uk.europe.earth.
A currency has a currency name, a parent namespace, and a set of zero or more governing stewards.
A currency can be public or private:
A journal entry containing
|names are reserved within a parent namespace for the four categories below:||class of steward (as recognized within a particular namespace)|
|governing steward||permitted user of space||part user||audit user|
|A steward with governance privileges on this namespace.||A steward with normal access rights granted conditionally by a governance steward of this namespace.||A steward with restricted access rights granted conditionally by a governance steward of this namespace.||A steward with monitoring/audit privileges granted conditionally by a governance steward of this namespace.|
|namespaces||Set this namespace as public/private||Create, own and govern namespaces within this namespace if authorized by a governing steward.|
|Enable/disable transactions in this namespace.|
|Admit/deny applications by other stewards to create new namespaces within this namespace.|
|Enable, disable or delete stewards in this namespace.|
|currencies||Set currencies within this namespace as public/private.||Create, own and govern currencies within this namespace.|
|Enable/disable transactions using this currency.|
|Admit/deny applications by other stewards to create currencies within this namespace.|
|Enable, suspend or delete users of currencies namespace.|
|accounts||Admit/deny applications by other stewards to create accounts within this namespace.||Create, own and govern accounts within this namespace.||
Read specified account in this namespace.
Write to specified account in this namespace.
|Read specified account in this namespace.|
|(name:currency) pairs||Enable, suspend or delete users of currencies namespace.|
More on terminology
The following terms are used below:
The term parent refers to the namespace in which any named object exists.
The term child namespace refers and a namespace contained within another (the parent namespace).
The term grandparent parent refers to the namespace in which the parent of any named object exists.
The term ancestor refers to any level of nesting from parent upwards.
The term descendant refers to any level of nesting from child downwards.
The following options are configured at the time of the initial setup according to policy:
Disabled by default.
Disabled by default.
relationships between named objects
recursive nesting of namespaces
The following diagram illustrates the recursive namespace structure.
Here the namespaces are labelled (untypically) in way convenient for identifying the depth of nesting from a root namespace.
At the top is a set of root namspaces (labelled "a1", "a2" ...).
Nested within these namespaces are more namespaces (labelled "b1.a1", "b2.a1", ... , "b3.a3", ...).
And so on.
This can be represented more compactly as a tree ...
... making it easier to visualize the recursive nesting of registry namespaces.
The coloured regions represent registry namespaces, which are equivalent to installations (not necessary implemented using the same technology, the only requirement being that they all conform to this very inclusive specification).
The recursively-nested structure mirrors that of the VSM. This is a natural design choice given that the REA system embodied is intended to support the viability of human-supporting systems.
Note: This approach to federation (across possibly very different implementations) requires little if any special provision. The mapping of a primary user identity in one registry to a secondary user identy can be achieved by extending the API (possibly with a single additional endpoint) to enable the mapping data to be transferred from one instance to another. Oauth2 may suffice for authentication across instances, although additional levels of security may be embodied in a simple supplementary protocol.
However, within the scope of a particular registry namespace (which is equivalent to a specific instance/installation), some of the many metasystemic tools can be integrated in a way that federated/clustered sets will not.
The term open money (two words, lower case) is an aspect of free speech - it is a context (see REA), and open money can be called free money (as in free speech, not as in free beer/lunch/load/ride).
The term openmoney (one word, lower case) refers to any software able to support the requirements of an open money implementation, operating in accordance with the principles and intellectual properties of the LETSystem Trust.
For background information and history, see the collected links page.
NB, open money is a special case of a broader concept: open metrics. The specification above generally applies to open metrics implementations as well.
Note: Although originally designed to support user-centred ledger systems (LETSystem model), a sufficiently secure implementation of software conforming to this specification could be be used as the ledger system underpinning any ledger-based service, including mutual credit services (such as LETSystems), loan-providing services (such as credit unions and CDFIs), energy-accounting systems, time banks or any other conceivable system recording events associated with resources and agents.
The openmoney client implementation may make provision for the user's public and private key to be generated deterministically using its name and password.
At the time of the most recent update (see date below), the original Swagger 2.0 API definition is being updated and extended to create an OpenAPI 3.0 API definition. That will then be used to create a new set of consistent client and server stubs.
* In the current test/development implementation the user logs in using a password instead.
A minimal testing/demonstration implementation to illustrate and explore core principles was written by Dominique Legault, who also wrote the original draft of this specification in collaboration with Michael Linton.
Terminology: Since every user of any openmoney software has the potentiality to be a steward, no distinction was made between these terms in earlier versions of this document. For the same reasons, the testing/demonstration implementation of the software treats all users with a login accounts as stewards.
(In the current demonstration/test implementation, the only root namespace available is fixed as "cc" so every user is given the namespace "username.cc" upon registration.)
A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name.
Version 2.0.53 [Previous numbered version]
This document has been gradually expanded (in various stages between 2020-06-28 and 2020-08-14 by John Waters) from the earlier specification (written by Dominique Legault and Michael Linton) in order to incorporate additional notes, annotations, etc.
[The source for this page.]