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.
For more details, please consult the glossary.
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.
This invitation is likely to come in the form of a QR code, bar code or something with equivalent capacity to carry the information necessary to ensure that the new registrant is taken directly to the correct namespace before being invited to enter its choice of unique identification and contact information such as:
In general, namespaces and currencies will not be exposed for accidental discovery. The overwhelming majority will be of no use or interest to any particular agent, and it is extremely important not to overwhelm it with irrelevant and confusing information. The useful information will be exosed gradually as it becomes relevant, by introduction/invitation rather than by discovery.
When registering, a user may optionally provide an email address and choose its notification settings (which can be 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" or a suitable equivalent in another alphabet [see note 9]).
Once registered, a user may join any number of namespaces (subject to the permission of 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 "." always represents the nesting of one namespace within another.
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 measures (a.k.a. open metrics). The specification above generally applies to open measures 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 automatically for local encrypted storage, unlocked by username 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.
The specification remains to be extended to support this.
A reference/experimentation prototype (NESTS) is currently under development, and discoveries made through this are gradually contributing to extensions to this specification.
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.
Although the descriptions above use unaccented Latin characters, names should ultimately be expressible using any character set. For the this reason, the NESTS prototype currently under development allows namespaces to be constructed from UTF8 strings, and allow any suitable UTF8 character be be configured as the namespace separator, and it seems reasonable to assume that any implementation will take a similar approach.
Version 2.1.6 [Previous numbered version]
Note 9 above (on internationalization) was added in version 2.1.1 and expanded in version 2.1.2.
A registry can exist in any namespace. This was not clear in the previous version.
A user may be identified by either its primary identity or any of its secondary identities, in both cases by full namespace path. This was also not clear in the previous version.
The registry section near the top of this page has been expanded to clarify the way in which users will grow their/the networks.
The section on terms used at the beginning was added in version 2.1.3. This was moved into a separate glossary with version 2.1.4.
This document has been gradually expanded (in various stages between 2020-06-28 and 2021-04-13 by John Waters) from the earlier specification (written by Dominique Legault and Michael Linton) in order to incorporate additional notes, annotations, etc., and to clarify the precise mean of, and relationships between, the various named entities.
[The source for this page.]