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:
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.
Contents
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
In the standard web-based paradigm, this layer would be referred to as "the server side" since it's the system at the other end of the HTTP connection that the interface environment (JavaScript/DOM) is communicating with. In our case it doesn't make sense to call it "the server side" because it's a service running on the same machine as the browser in which the interface is running (connecting through localhost using HTTP as a Single Page Application).
The primary purpose of the network layer is to provide the users and groups oriented functionality including the persistent storage of their content. It does this in a peer-to-peer configuration, and keeps the group's ontology consistent in real-time (as long as a network connection between them is present).
There is actually no technical difference between a user and a group, the only real difference is that in the case of a user only one person has the PGP key to access its private content, but in the case of a group node a number of members have private access. The node's content, structure and functionality will then evolve accordingly becoming more single-user or group oriented over time.
Authentication involves an interface device allowing a user or process to use its private key to open a "session" through which it accesses a nodes internal content, functionality or resource. "Session" is just a fancy name meaning; time during which a viewer application is connected to a user or group node in the network. There could be many active sessions viewing a particular node since there could be many connected members viewing it and each could be logged in from many devices and locations at the same time.
It's the job of the network layer to ensure that all the change occurring within the content structure of a group is routed promptly to all the viewers of it amongst all their diverse locations and technologies. Each group can be considered as a live collaborative "channel" where its members are subscribers to the content.
The interface layer
The interface is a viewer (in the MVC sense) onto the unified ontology which is a peer-to-peer network. The viewer is a standard web-browser based Single Page Application using the Livelets SWF method so that events can be propagated asynchronously from the local peer up to the browser instances, and interface events can be routed the other way down into the peer if necessary. 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
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).
- 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)
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
