openmoney software specification

Introduction

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.

users

Pronouns: Since a user may be a person or an organization, or possibly a machine, the gender-neutral it and its are used below.

registry

primary identity

secondary identity

user authentication

stewards

namespaces

namespaces enclosed entirely within one registry namespace

This section refers only to namespaces enclosed within the same registry namespace.

extending namespaces beyond a single registry namespace

currencies

accounts

journals



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:

Configuration options

The following options are configured at the time of the initial setup according to policy:

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.


notes

  1. open money

    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.

  2. wider applicatiions

    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.

  3. key-pair generation

    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.

  4. implementation

    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.

  5. inter-registry authentication

    The specification remains to be extended to support this.

  6. reference prototypes

    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.

  7. current root namespace limitation

    (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.)

  8. collision-resistant names

    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.

  9. Internationalization

    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.5 [Previous numbered version]

Changes

  1. Note 9 above (on internationalization) was added in version 2.1.1 and expanded in version 2.1.2.

  2. A registry can exist in any namespace. This was not clear in the previous version.

  3. 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.

  4. The registry section near the top of this page has been expanded to clarify the way in which users will grow their/the networks.

  5. 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.]


Creative Commons Licence
This work is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.