This work is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.
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 registry is a namespace within an instance of any openmoney-compliant software with/in which a user's primary identity can be registered.
A namespace enclosing all namespaces associated directly with users having primary identities registered in that registry is its registry namespace.
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.
Every user is identified in a registry by an immutable username and a public key [*] (which can be updated subsequently) [see footnote on key-pair generation].
A user's primary identity is that recorded uniquely in a registry (namespace).
When a user registers, it is given a private namespace, identified by username, within the same registry namespace. [See footnote].
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").
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.
Once registered, a user may identify itself using either its unique primary identity or any of its secondary identities, in either case using its full namespace path, e.g.
In the example above, the user identity henry exists in the namespace crun.goons.radio.bbc whereas the user henry_crun exists in the namespace goons.radio.bbc.
A "." always represents the nesting of one namespace within another.
A user with responsibility for a namespace is referred to as a steward of that namespace or, alternatively, as a governor or governing steward of that namespace.
A user with responsibility for a currency is referred to as a steward of that currency or, alternatively, as a governor or governing steward of that currency .
A user with responsibility for an account is referred to as a steward or, alternatively, as a governor or governing steward of that account.
The steward of a namespaces has unconditional privileges over that namespace and any namespaces, currencies, accounts and users within it.
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.
Every namespace is managed (controlled) by a set of one or more steward(s).
A namespace is an enclosure.
Every namespace can enclose other namespaces.
Every namespace can also enclose a set of currencies or accounts under the control of that namespace's governing stewards(s) - i.e.
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:
berkshire.england.uk.europe
berkshire.massachussets.usa.north.america
where both have the same namespace name at the start of the string but each has a different parent namespace.
Every governing steward of a namespace is notified when any of its other stewards creates a child namespace, currency or account there.
Every governing steward of a namespace has the ability to enable or disable any of its child namespaces, currencies or accounts.
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.
Every governing steward of a currency is notified whenever any steward creates an account that uses this currency.
Every governing steward of a currency has the ability to enable or disable accounts used by this currency.
Every governing steward of a currency gets a copy of all journal entries that use that currency.
A currency can be public or private:
An account has an account name, an account parent namespace, a currency, a currency parent namespace and a set of governing stewards.
Account stewards post journal entries from one account to another account in the same currency.
A journal entry containing
If the server is able to verify that the namespaces, currencies and accounts specified in the journal entry are all enabled, then:
A governing steward of an account can request a list of all journal entries for transactions to or from that account.
A governing steward of a currency can request a list of all journal entries for transactions in that currency.
Any governing steward of a currency has the ability to void a journal entry by posting a reversing journal entry on behalf of both parties.
| 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 named object below refers to any namespace, user, currency or account.
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.
Configuration options
The following options are configured at the time of the initial setup according to policy:
Allow a steward of a namespace at any ancestor level than parent to move any named object.
Disabled by default.
Allow a steward of a namespace at any ancestor level greater than parent to suspend or delete or (where enabled) move any named object.
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.
The specification remains to be extended to support this.
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.)
From https://tools.ietf.org/html/rfc7519:
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.1.0 [Previous numbered version]
Changes
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.
This document has been gradually expanded (in various stages between 2020-06-28 and 2021-01-10 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.]