Outline

Identifiers

An identifier is a unique string comprising a names prefixed to the identifier of a namespace (an entity the purpose of which is to enclose a set of names).

An identifier comprises a chain of names the leftmost of which is the name of the entity identified, and the remaining chain of names to the right of it forms the identifier of the namespace (its parent).

Therefore the identifiers ramify into a tree, the chain to the right identifying the ancestors and the tree (if any) branching to the left representing the descendants. The immediate ancestor is called a parent and an immediate descendant is called a child.

The most distant ancestor within a namespace tree is its root. The root namespace are children of a nameless namespace, the substrate, which is unique in being its own parent.

By default, the tree of descendants branching from a primid forms a private namespace tree the owner of which is that primid. That primid is its initial steward which may choose which other primids to invite to share that role. The steward(s) may choose to make public any sub-tree within that private namespace tree.

Any namespace not located within a private namespace tree is a public or open namespace.

Entity categories

There are four categories of entity:

• The namespaces (which might be thought of as representing some sort of local network, island, community or common bond) in which names of all entities (including other namespaces) are contained.
• The login identity (a.k.a. primary identity or primids), the unique identifierem> of an agent (whether a human, an organization, a robot or a device).
• The account-holder identities (ahids), which may be thought of as an alias of a primid, the name of which may be situated within an arbitrary namespace (where authorized by its stewards). An ahid can be paired with any number of distinct currencies, each such pairing indexing a unique account.
• A currency, which is both a set of accounts and a description of the shared properties of those accounts. Therefore it may also be considered to be the type of those accounts (variables). (The term "currency" is used for historical reasons, given its origins in the context of open money, but "variable type" would be a more general and meaningful term. Therefore the terms "currency" and "type" may be used almost as synonyms. Limited initially to scalar values of type money, the design of SLATE has already evolved to included the much richer set of variable types in the NESTS design, including scalars, vectors, matrices, pointers, time series and trigger thresholds.)
• An account (variable), a member of a currency (set).

Agent categories

An agent may be of many possible types, including, but not limited to, the following:

• human
• organization
• robot
• sensor
• effector
• DAO

There are two additional categories of agent:

• A steward (of a namespace or of a currency), is a primid assigned this role by an agent already holding this role or by a global system administrator.
• A global system administrator, assigned this role at setup or by an existing global system administrator.

Furthermore:

• An ahid may be paired with each currency (where authorized by its stewards) only once. Such a pairing identifies an account the identifier string for which is an ugly but unique string mapped from the identifiers of its two components, not generally visible (although in some operational modes it might be made so). For the purposes of such pairings, the identifier of a primid also has an ahid registered to it.
• A primid may have any number of ahids.
• Each ahid has only one primid.

See internal representation.

A short note about implementation

NESTS was conceived originally as a very low-level web application with minimal dependency upon components with uncertain longevity or upon the features provided by any specific programming language, deriving its versitility partly from the essential and invarant properties of UNIX-like filesystems. However, much of the heavy lifting has been off-loaded to SQLite given its stability and very widespread use (and simplifying a subsequent shift to PostgreSQL should there later turn out to be acompelling reason). At the same time, whereas Python was used initially as a convenience for prototyping and maintenance, the contiually growing power and breadth provided by the Python Scientific Stack to address requirements further along the development roadmap has led to an expectation of dependency (although not to such an extent that gradual re-implementation, even if rather incomplete, cannot be achieved using faster, more scalable alternatives).

SLATE conforms quite closely to the open money software specification although that is overdue for some fairly minor revisions (most notably the subsumption of the role of secids by that of ahids).

Current status

The current version is incomplete and some functions have not yet been (including those for managing the pruning and grafting of namespace trees, various stewardship tools, and much else). However, it is already usable for experimentstion, modelling, simulation, and much else.