Software architecture

The purpose of this document is to define a software application designed specifically to match the platform specification which is summarised following:

Platform: In the Organic Design context, platform refers to an organisation that is using the platform specification as the foundation of it's system design, so that it operates in accord with the values outlined in our charter and manifesto. Part of the platform specification is that all platforms have some common departments such as networking and deployment which allows them to share knowledge and create new Platforms through common interest and shared vision. The platform network refers to the collection of all the platforms connected together to form a global peer-to-peer network that achieve their goals together in alignment with each other and the common good using self governance. [more]

The software architecture describes the implementation of the specification within the context of our own Linux distro (eventually a GNU Hurd distro) which has a web-desktop integrated at the Window-manager layer. We will make it available in a limited way via exiting operating systems running a client application, and in an even more limited way purely from a browser with no client application present, but the primary aim is for end users who are running the complete operating system solution, and this architecture document will be covering that perspective as its default context of discussion.

The software architecture can be generally divided into three main abstraction layers called the "network layer", the Foundation Ontology and the "interface layer". There is then an "application layer" on top of this which is not considered to be part of the software since it's in the form of content including persistent objects representing a real-world ontology of such things as trust groups, members, resources and systems.

The network layer

The system is completely serverless (i.e. fully peer-to-peer) and needs to be capable satisfying the following requirements completely within the serverless network environment without relying on any third-party processes or resources outside the network.

• storage of "simple content" (like a DHT - larger arbitrary files can be managed at a higher level of abstraction)
• authentication (using standard key-pair technology but leveraging p2p and trust relationships)
• secure private trust groups (containing simple content)
• near real-time streams between peers and groups

The bottom level of functionality then is the "peer" which is a running instance of the software, which in turn supports the formation of the higher-level entities of users and groups.

Foundation ontology

Within the context of the software architecture, the Foundation Ontology runs in the same runtime environment (i.e. same programming language etc) as the network layer. It means that a peer can be a fully functional part of the network even if it has no display capability (i.e. a "headless" server configuration).

Foundation Ontology: A system of operating as an evolving organisation is common to all nodes in the Ontology, the conceptual structure of this kind of organisation that captures these principles of collaboration and self-governance is considered to be the Foundation Ontology for the Organic Design system. The Foundation Ontology is a common form of organisation that spans both real-world organisation, and informational systems alike, it defines what it is to be a node in the unified Ontology. Since the Foundation Ontology defines the attributes that are common to all organisations in the network, it's important that the bottom lines designed in its system remain aligned with the core values and common vision. [more]

• content revisions and history
• persistent user sessions into the persistent groups
• scheduling and workflow
• exchange and accounts (note that this could require dedicated support from the network layer since it's extremely difficult to achieve in a solid way and needs to tie in closely with the p2p and security aspects. We envisage integrating the network layer with Bitcoin to achieve this aspect.)
• package management (installation of external functionality)

The interface layer

Renders 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 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

• Software architecture notes - a lot of notes to be merged into this article
• Unified Organisational System - some useful notes in this older doc