The Cyborg project is an extensible platform that provides tools to synchronize and coordinate large groups of people, machines and sensors to achieve specific tasks.

Cyborg’s core focus is to:

• make the results of one command easily flow into another command.
• make the interfaces simple enough to allow for rapid development by letting the developer plug-in at a high level of abstraction yet remain close to the problem domain.
• make it such that oz is the preferred language to implement most new features for the Cyborg project.

People form graphs of real world connectivity, they have shared frequently visited locations. Movement between these locations are managed by time slots on a calendar. People have contacts with whom information flows to and fro. With this information and the correct tools it becomes possible to make use of software to coordinate large groups of people.

A task list or more commonly called a to-do list is an arguably efficient way for people to manage their daily lives. It so happens that many task lists released today only amount to this. Few task lists are designed such that a user may assign a task to another person or group of task lists. Cyborg aims to go one step further by allowing users to install interesting cyborg add-ons, thus giving it permission to assign tasks to their task list. The task list is the main interface for add-ons to interact and coordinate humans.

Recap:

• Users may assign tasks to themselves.
• Users may assign tasks to other users or group of users.
• Users who installs a cyborg add-on allows it to assign tasks to their task list.

CJDNS (see below) gives each user a static ipv6 address. Each Cyborg add-on is responsible for maintaining their own contact list. The cyborg platform hosts a number of different cyborg add-ons which coordinate with other cyborg nodes that have the same add-on installed.

A message is quite simply an immutable packet of information transmitted to another agent/person. Oz supports the message passing paradigm correctly. Correct message passing in conjunction with a contact list filled with static ip addresses makes for a communications platform whereby many limitations of email, such as security, capped email limits become moot. As message passing is built into the oz language, the bar to send a message to someone now gets almost entirely removed. There is no need to learn a new protocol (ie SMTP) then develop a client program that talks SMTP. This system allows one to simply send your message to another user directly from the programming language. Oz’s distributed sub-system then takes over the responsibility of getting the message to the destination.

The Cyborg platform, debugging tools and a few core distributed applications are packaged, developed and maintained by the project developers. Third party cyborg add-ons are created by individuals interested in scratching their own itch by creating their own agent add-ons.

A list of possible agent add-ons.

The Cyborg project takes a leaf out of Emacs’s book, by structuring itself according to the classical Model, View and Controller pattern. Please read this paper [Dynamic Applications From the Ground Up by Stewart, Don; Chakravarty, Manuel](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.1406&rep=rep1&type=pdf)

Cyborg has a small static core just surrounding the Mozart VM2 other than that the entire application is dynamic and may be hot swapped.

Just as text is the primitive for an Emacs buffer so oz source code is the primitive for a cyborg buffer. Emacs has modes (text highlighting, org-mode etc) which operate on different types of text (c++, erlang code) so cyborg has different modes of displaying the oz source. There could be at least five modes:

• a scratch pad - allowing the user to throw experimental code at the oz vm.
• raw text, allowing for heuristics, malicious code checks to be performed.
• light table clone with debugging information.
• scratch / blockly clone with debugging information.
• as the final product executed or runtime mode.

Once a user starts Cyborg the default for a cyborg add-on is runtime mode. This means the user is faced with the programmed user interface intended by the cyborg add-on developer. Initially Cyborg will only support raw text, scratch and executed mode. The important factor is that Cyborg support modes. Developers may create new and interesting modes to represent the code.

Cyborg uses Gecko part of the Boot To Gecko project as its view. Cyborg add-on developers use the Mozart Oz Qui library inspired by the QTk library. The Qui (Quick User Interface) library supports a declarative oz syntax to construct the user interface. Once executed the Qui library will translate the declarative oz code into non-behavioural JavaScript and emits it as cappuccino runtime JavaScript code into Cappuccino running inside Gecko. Which then executes and updates the user interface. Browser events are ‘hijacked’ via Cappuccino’s messaging system and rerouted back to the oz vm which processes the associated behavioural actions. Upon completion non-behavioural JavaScript is emitted back into Cappuccino. In effect we are only using JavaScript to do declarative gui rendering and surgically removing JavaScript processing of actions in favour of oz - a rather more predictable language.

The heart of Cyborg is the embedded Mozart Oz 2 virtual machine. Oz code dominates the controller: all commands the user invokes, whether from the keyboard, finger gesture, a menu, or by name is an Oz function. A command is simply a Oz function which has been marked as suitable for interactive use. The name of the command after the particular key sequence ie `Meta + x` is the oz function. Keymaps bind key sequences, mouse clicks, gestures and menu selections to commands. The keymap dispatching process means that oz code is almost never responsible for handling events from an event loop. Different keymaps are supported, much like Haskell’s Yi editor.

A few important features are needed to allow for rapid, organic, safe feature extension:

• A .cyborg file can load existing packages of oz, set variables that affect Cyborg’s behaviour, redefine key sequences.
• Each cyborg add-on has its own repo, simply cloning a friends cyborg add-on into say ~/.cyborg.d/cyborgaddon then editing your ~/.cyborg file to include that cyborgaddon into your running cyborg instance. One could refresh and cyborg will pull in the changed file from your ~/.cyborg.d dir made by emacs/vim etc.
• Oz is interactive. One can enter expressions into Cyborg’s scratch buffer and evaluate them immediately, re-factor an expression and re-evaluate it. There is no need to recompile or restart Cyborg.
• Each Oz program is a first class citizen. Which means that Unix style applications (do one thing and doing it well) others write may be used by other developers. Buffers, windows and other distributed oz objects appear as ordinary oz code. Cyborg arrogates no special privileges to itself within the Controller
• Oz is a full programming language.
• Oz is safe. Buggy oz code cannot crash Cyborg. Promoting experimental development.
• Oz has a neat module system called a functor, allowing developers to easily share code with one other.

• A developer thinks of a neat cyborg add-on to write - using Cyborg’s pleasant, interactive development environment one may develop the application or tweak parts of an application.
• Once the expression works it can go into the ~/.cyborg file to make it available permanently.
• This then expands out into a suite of commands that work together. It can be packaged easily and shared with friends via a DVCS.
• The refined package could be included in the market for general consumption.
• The most popular and reasonable market add-ons are included in the canonical Cyborg distribution.

Boot to Gecko (B2G) is a Mozilla project with the goal of building a complete, standalone operating system for the Web. Currently it targets mobile devices. It consists of:

• Gaia : The user interface of b2g. Everything drawn to screen after b2g starts up is some part of Gaia. Gaia implements a lock screen, home screen, telephone dialer, text-messaging application, camera app, … and many more. Gaia is written entirely in HTML, CSS, and JavaScript. Its only interface to the underlying operating system is through Open Web APIs, which are implemented by Gecko. Gaia works well when run on top of b2g; however, since it only uses standard web APIs, it works on other OSes and in other web browsers (albeit with degraded functionality). Third-party applications can be installed alongside Gaia.
• Gecko : The “application runtime” of b2g. At a high level, Gecko implements the open standards for HTML, CSS, and JS and makes those interfaces run well on all the OSes that Gecko supports. This means that Gecko consists of, among other things, a networking stack, graphics stack, layout engine, virtual machine (for JS), and porting layers.
• Gonk : The lower-level “operating system” of b2g. Gonk consists of a linux kernel and userspace hardware abstraction layer (HAL). The kernel and several userspace libraries are common open-source projects: linux, libusb, bluez, etc. Some other parts of the HAL are shared with the android project: GPS, camera, among others. You could say that Gonk is an extremely simple linux distribution. Gonk is a porting target of Gecko; there is a port of Gecko to Gonk, just like there is a port of Gecko to OS X, and a port of Gecko to Android. Since the b2g project has full control over Gonk, we can expose interfaces to Gecko that aren’t possible to expose on other OSes. For example, Gecko has direct access to the full telephony stack and display framebuffer on Gonk, but doesn’t have this access on any other OS.

As B2G is designed to only support HTML5 apps, installing linux userspace programs on Gonk isn’t really possible. Thus the B2G project will need to be forked. Mozart Oz 2 and CJDNS will need to be ported to Gonk, then installed. A ZeroMQ instance will then facilitate communication with Cappuccino running in Gecko and the Oz vm. Gaia could be retained and Cyborg exposed to the user as an icon on the Gaia desktop.

The motivation behind Mozart Oz as the language of choice is purely driven by the need for well supported programming paradigms which includes strong distributed computing support. Oz has a many desirable features such as multi-core support, constraint programming, functional programming (the oz compiler itself can be called in a functional manner) , object-oriented for user interface programming. Dataflow support at a language level; thus the corner stone of many a paradigm, as a result of this oz supports most of the major paradigms in a factored, well thought out manner. Oz is a dynamic language which supports ‘line feeding’, thus making it suitable to easily throw expressions from the cyborg scratch pad into the vm. Oz allows for features such as roaming objects, which can be sent down the wire to other nodes in the network to perform operations. Above all - Oz’s management of state means the there are no race conditions. Many paradigms in oz are deterministic, those that aren’t use neat techniques to cordon off non-determinism such that it won’t burn developers into a fiery hell of despair - a much needed feature considering cyborg is fully distributed. [mozart-oz](http://www.mozart-oz.org)

“cjdns is a routing engine designed for security, scalability, speed and ease of use. The dream: You type ./cjdroute and give it an interface which connects another node and it gives you an ipv6 address generated from a public encryption key and a virtual network card (TUN device) which you can use to send packets to anyone in the cjdns network to which you are connected.” [cjdns](http://cjdns.info/)

CJDNS allows a node:

• to become its own micro-ISP.
• to have a static IPv6 address derived from a fingerprint of your public key.
• to route packets without memory look ups.
• to be resistant to denial of service attacks.

GPL3