Software architecture
|
This article describes a software architecture that supports the Organic Design vision in accord with the core values. The general topology of this system is a nodal network where every node has a unique identifier and represents a specific persistent object.
Contents
The logical layer
The term object in the above short description is used in the sense of prototype-based object-oriented programming, where an object is effectively a container of properties, arbitrary content, other objects, and methods accessible via an API. So the informational structure of the object is essentially a hierarchical collection of key/value pairs like a JavaScript object.
This network of objects is called the logical network layer and exists persistently regardless of the nodes coming and going in the physical layer of actual devices and processors.
So far what we've described is quite a standard sort of network these days that's used in all sorts of projects, but one thing to bear in mind is that the keys and values (when thinking of the object as a collection of key/value pairs) can be hashes that refer to other nodes in the network, and that this is the usual way that they're used in our system. It's still fine to have keys and values of the usual textual kind too so that objects can contain any diverse content, but for the purposes of this article we should always think of them both as node references.
To be more specific: The network is a peer-to-peer network of hashes similar to a DHT. The hashes are globally unique identifiers that contain an arbitrary set of related node-hashes where the connecting relation is also a node-hash (i.e. a triple-space). The target node can also be arbitrary text, or a URI allowing the nodes to effectively contain any kind of resource or content.
The physical layer
The physical layer doesn't need to be discussed in any detail here, but suffice to say that the technologies composing the Internet of Things provides the perfect framework in which to host such objects, and ensures that any object has the ability to establish communications channels with any other object via the most efficient path.
The physical layer is composed of actual real-world resources, and each of these resource-types and each physical instance of these types all have corresponding nodes in the logical network through which they are organised and managed. So we now have three conceptual sets of nodes: purely logical nodes, physical resource types and physical resource instances.
These resources cover all types of processors, storage and bandwidth and cover all scales from processes running on a devices up to human roles working on machine. All of them are integrated into the network by having their methods connected into the logical network to be presented as a standard API that other nodes can interface with.
Class/Instance
The process of creating a new node requires that it be an instance of another node, creating new completely empty nodes is not possible. This leads to the network being a tree structure with a root node. This means that all nodes in the network inherit the functionality of the root node.
Instances can have any amount of content added or even content removed, so the fact that they have to be based on something is not a limitation, but allows the network to keep track of what nodes have in common with each other and how they differ.
Relationships
The root node is also the one that implements the base relationship functionality that comes from a node being connected to other nodes.
The entire effect that the relationship has on the end-nodes of a relationship is done by the relationship node. This is the basis of the "action not opinion" value, the meaning of a relationship is a description of what it does.
...
Space
All the types of resource are organised into a tree, and nodes can "own" a certain amount of any of these. All these resources are able to flow around the network through channels (which are also resources) that connect the instances of resource. All these resources can be connected by their APIs with simple connector scripts (either on or off chain depending on context). Nodes can be made into complex hierarchical structures of services and contracts to represent larger-scale functionality such as organisations.
...
Time
The scheduling method by which these services interact with each other over time is encoded purely by the semantic relationships between them. This scheduling aspect covers parallel and serial structure of order as well as event-based connections. A normal schedule is a bunch of "slots" of time and resource into which specific instances are allocated.
In this system the same is true, where the slots are specified in terms of roles, and they're organised in a semantic relational network specifying order, hierarchy and events instead of just the normal linear timeslots. The nodes are the resource instances, but the way they're connected together forms the energy aspect.
Energy
An energy-oriented view of any node is available since its resource usage over time is known. This gives rise to the ability to budget (cache) and determine the total active and potential energy of a node. What products and services its possible to perform and what profit and loss this entails.
Organisation
The way all the aforementioned functionality works is encapsulated into the generic organisation node, which is the most general template for starting a new organisation, ether at the computer process scale, or the real-world people-oriented scale.
Interface
The viewer is the default generic organisation at the computer process level, and the trust group is the default real-world people-centric generic organisation. After trust groups are more refined we'll start defining platform more clearly which brings physical operating premises into the equation.
The viewer is a standard web-browser based Single Page Application that connects to the network via a local service. The browsers current URL determines the node in the network which currently has focus, and the specific context within that focus such as views, sub-views and actions.
We've made an experimental start on this idea which is being documented in the Nodal interface using corMVC article. The most important point in this URL format is the hash character since no change in the URL after that character is considered to be outside of the current document, so the entire viewer session is self-contained into a single DOM instance requested only once at the start of the session.
When the node ID changes by clicking on links or buttons in the application, JavaScript events are called by the DOM which update the page and may involve an AJAX request through localhost to the local peer instance for other nodes' content in the peer-to-peer network.
Its job is to render a users persistent user session which may include many concurrent logins across a number of devices allowing applications and hardware (such as processing, storage, bandwidth, inputs and displays etc) to be shared amongst the devices producing a single "desktop environment" together. Each user generally has just one persistent session at a time (although there's nothing to stop a "power user" from running many concurrently or shelving some for later use etc). Such persistent sessions are viewed using the locally available "views" in a "network viewer" application (an interface layer typically running on a machine connecting through localhost to a network layer "peer" instance).
The running interface layer is only temporarily active in RAM and is typically running in a browser DOM environment (in the form of a single-page application) and lasts for the duration of the user login. The currently selected "view" within this browser DOM environment is even more transient but is considered as one of the abstraction layers since it's the conceptual equivalent of a running application in a desktop environment.
- peer → trust group → user session (persistent) → interface session (not persistent) → view
Applications
We consider "applications" to be defining "what a trust group can do", for example following is a list of some of the common requirements a typical trust group would have in the network. This list sounds like some pretty normal readily available functionality, but bear in mind that all of this takes place in peer-to-peer space with complete privacy when desired and without any dependence on any kind of third-party external resources or services.
- maintain content together (like using a wiki, blog or other CMS)
- maintain media channels (e.g. shared playlists or radio stations)
- maintain software and packages (work on code together and manage releases)
- govern and make decisions together (see group decision-making and self governance)
- manage projects together (assign tasks, raise issues, track time etc)
- engage in commerce together
See also
- Organic Design's ideal channel system
- Nodal interface using corMVC - making a start on a viewer onto the unified ontology
- Software architecture notes - a lot of notes to be merged into this article
- Unified Organisational System - some useful notes in this older doc
