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 allows the formation of users and groups.

Foundation ontology

• content revisions and history
• persistent user sessions into the persistent groups
• scheduling and workflow
• exchange and accounts
• 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.

Peers → 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 here's a list of some of the common requirements a typical trust group would have in the network.

• 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 (and remember the requirement above of not relying on external third parties for any of this functionality)

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