Software architecture

1. The purpose of this document is to describe a collection of free open source software projects that can be packaged together to form a larger system that allows groups using it to work as a Platform in the Platform network.

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

Requirements

The software architecture requires the following of the software (since the Platform specification has those same equivalent requirements of a Platform organisation)

• Community developed free software
• No third-party servers - just the peers composing the network
• Trustable privacy with reliable decentralised storage and communications including media distribution
• independent private commerce between peers and groups in the network
• Decision-making and self-governance tools
• A unified address space for collaborative content (shared ontology)

Technology stack

An architecture is a description of a system which covers a number of abstraction layers and which is often referred to as a "technology stack", for example the W3C Technology Stack.

Common interfaces between abstraction layers of operation allow the technology in each layer to be satisfied by different vendors or projects, such as in the layers of hardware architecture, operating system and browser, where each provides a standardised environment that the other layers can interact with regardless of which of the many available options has been selected for it.

Internal & external aspects

There is also a dichotomy of "internal" and "external" which apply both as a whole, and also to each layer in the stack which all have their own aspects that fall into both the internal and external sides.

For example the World Wide Web can be seen from the "browser side" (inside the web) as a collection of documents and application-forms within a tree of domain-names and file-path names. But there is also a "server side" which is outside of the web since it can't be reached directly from in the "web browsers" and isn't composed of HTML content that a web-broswer could even recognise. This server side is composed of physical network connections and computers, filesystems and operating system services etc.

In terms of technology stacks, the external side of the Internet is computers and ethernet connections at the bottom, then IP addresses and domain names on top of that, and then protocols for web pages, email and chat etc and finally interface such as browsers and desktops at the top. The inside aspect's stack involves concepts such as users, groups, document types, active user sessions, folders, windows, forms and buttons, events and schedules etc.

Our stack

external	internal
-	-
-	-
-	-
-	-

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