The Object Network
Above is a sketch of a possible user interface to a radically new way of building and programming our virtual environments.
It's an approach that's needed now, because computers and our virtual property are starting to merge invisibly into our surroundings, demanding new ways of interacting with them.
The imminent proliferation of small, internet-connected devices in our homes and the arrival of increasingly sophisticated forms of augmented reality mean we will start to lose track of the boundary between real and virtual.
So you need to be able to see, control and program the virtual stuff that you own. That's what we mean when we say "program reality"!
The Object Network approach aims to model the real world as closely as possible, so that programming your virtual reality is just as intuitive and natural as your interactions with normal reality.
For example, we have familiar "objects" with sets of "properties". These objects link up into bigger structures. An identifier or link called a UID - similar to the familiar URL or web link - is used to build those links.
As you can start to see by looking at the sketch above, the state of an object can depend on the state of another one that it links to. Here, the light depends upon the state of the price tag, alerting you that you should run out and buy the fish tank!
These two objects are hosted on different devices. The light object could be running on your home hub, which may be controlling a Lifx bulb on the home net. The price tag object would be on a machine owned by the petshop. But the light object can "see" the tag object through its UID.
The light can advertise its own object UID via a beacon, either on the bulb, or on the nearby hub driving it. Beacons, QR codes and GPS provide anchor mechanisms between the real and virtual worlds, allowing the virtual world to be made visible and interactable via augmented reality.
Things can be animated by visible rules which define their behaviours and interactions with other things. Rules enable your objects' states to be dependent on that of other local or remote objects that are visible via their links.
You could link to available custom rules online published by others, but more interestingly, you could write your own object rules to allow them to have any behaviour you like.
The picture of the interface above shows how objects are bundles of properties at a link or UID. They can link to other objects with UID properties - shown as a nested object here. Lights and price tags (and contacts and calendar events, and 3D entities, and chat messages..) will be standard types that everyone can use.
The example shows a very simple rule built in this 2D interface, comprising two objects: a light in your home and a price tag in a local pet shop - an object that is hosted near a fish tank you want to buy.
A rule like this matches the conditions in yellow and rewrites the object when that happens - the right-hand side of the "=>" symbol.
The rule is 'animating' the light and represents its dependency on the price tag - when the price drops, the light goes red.
The rule would run on the light itself, or maybe a controlling host such as a house hub. The price tag would be running on a machine owned by the pet shop, and these two machines, or their two objects, will talk directly, peer-to-peer, to make this rule work.
If you can write spreadsheet formulae or HTML, you can write Object Network rules. These rules can be written in traditional one-dimensional text, or in a two-dimensional user interface.
This rule programming language is very high level in the sense that you don't need to do any work to write code for saving objects or to handle their network interactions. It also assumes the code to handle input and output is already in place - e.g. the light driver above, or user interfaces. You simply write your actual logic, in a very declarative way.
Objects simply link to the rules animating them. Rules are objects and would also update just like the stuff they animate, so can always be kept up-to-date.
Objects will depend on each other, like cells in a spreadsheet, and there will be ripples of updates across peers. Things can settle in their own time - which is more like reality and more robust. Pretty much anyone can program spreadsheets, and anyone will be able to program their own stuff in the Object Network in a similar way.
This open web of objects will form a system of local, autonomous, peer-to-peer relationships. The Object Network replaces lock-step central control with behaviour and interactions that emerge from local decisions. Rules are lightweight and work together so that behaviour and interactions emerge from many such small rules being applied or triggered on individual objects.
Contact me and/or subscribe to my blog and/or follow me on Twitter.