There are three keys to the design of the Object Network: Identifying every physical thing, linking them all up and declaring the dependencies between them.
The Object Network would like every thing in the Internet of Things to have a unique identifier to find it by.
Each of your home lights and dimmers, each air quality sensor or street sign. Even the rooms each device is in and each house and the street the sensors are on. You yourself and other family members interacting with those devices can be identified!
Every physical thing that can have a digital presence should have a unique identifier.
Each of these items is called an "object" in the Object Network. Objects are just small chunks of data. The objects' identifiers are called "Universal IDs" or UIDs. They could, in fact, be web addresses or URLs. They could be addresses on the internet (IPv6). They could be UUIDs.
Any short line of text can be used to identify an object, as long as there's a way to look it up. Anything that can be used to identify and track down an object can be a UID. All that matters is that the UID can be "cashed in" for a copy of the object's data - whichever machine or device is hosting it.
So everything, every object, has a UID, but each object is not isolated: the Object Network would also like to be a global mesh, a fabric of objects linked up around the planet. Any object can point to or link to any other object simply by keeping that object's UID within itself.
Your light can hold the UID of the room it's in, which links to the other devices there, such as the dimmer. The room can link in turn to the house, which can link to the street and then to the street lights and air quality sensors...
It's a lot like that other global mesh: the web; only now we really want every physical thing to be identified and linked up into the global digital fabric, not just web documents.
Once you (or your digital self) have a link to something or someone, you can watch them change, and they can watch you change in turn. In fact, any thing can watch anything else and change when it changes.
A light can link to the air quality sensor in the street and set the colour of your dining room to reflect its readings. Or link to the temperature sensor and go blue when it's going to be icy. You can link a sound generator to a door sensor. Link a heater to the room to detect when someone enters (the room will link to them!) along with a link to the temperature sensor, so the heat can be turned on when needed.
All this interaction, all this watching of each other changing, happens between computers, devices, mobiles, etc, directly or "peer-to-peer" over various networks under the Object Network.
Obviously you can decide who has permission to see your own stuff: an individual, a group, or everyone.
In real terms, the Object Network can be implemented by a small chunk of open source C code - to be called Onex - that can run on, say, your ESP8266 or ESP32 devices: sensors, actuators and user interface boxes, or on your mobile, PC or Raspberry Pi.
This code provides a simple data notification layer that runs over device storage and networking. This realises what you see in the diagrams above: linked interacting objects at the end of UIDs. If you squint, you could get away with calling it an operating system.
The user interface (perhaps TFT/OLED basic graphics or GLES 3D) will let you explore and interact with the network of objects; to see sensor values, adjust lights and chat with or play games with other users. You can create new objects and copy-paste their UIDs to link them up, either in the home or across the planet.
Inter-object dependencies can be programmed over Onex in C via an API, or on the user interface device via a simple 2D programming language.
The Object Network is like the web, except it gives an address or identifier to all our physical and digital stuff (objects), not just web documents. Further, it deals with updates to those objects, so no more hitting "refresh". These objects can be created and published by everyone, from their PCs, mobiles, and devices. In other words, objects are dynamic, two-way data, not static, one-way documents.
Relative to operating systems, Onex doesn't offer low-level functions for threading, networking, storage, etc, but rather a single high-level abstraction of these linked up local and remote objects.
And relative to other programming models or languages, Onex has a pure functional model that - unlike other functional languages that try to avoid state - transforms the state of objects, when made aware of changes in state of other objects on which they depend.
There are no sealed applications or centralised services in the Object Network, it's just a continuous, seamless "fabric" of everyone's live stuff interacting within and between homes, including everyone themselves.
Onex raises the level of abstraction that you build your Internet of Things or Virtual Reality with. It takes care of managing, cacheing and updating objects, and hides the network so you don't have to work out how to exchange data between devices on the LAN or WAN.
Wiring up devices, places and people with UIDs and writing simple high-level code to describe how they inter-depend is simpler and more powerful than writing custom low-level code (which usually does pretty much the same thing each time you write it anyway).
You can point a toy dog or a 3D virtual dog at your grannie's room light switch and write a rule to make it jump when the light's turned on. All without central services and multiple app logins and learning several different ways of doing the same thing.
Anything you can think of to do with your digital stuff, and how it depends on other's stuff, is within your grasp. Everything's visible and watchable at the end of a link or chain of links and everything you create is under your control and can be animated with simple rules. There are no limits to the ways we can link up, watch and control our networks of smart devices.
If you'd like to help me build Onex, you can contact me, Duncan Cragg, via the email or Twitter details at the foot of this page.
Or read this Object Network walk-through scenario to see in more detail how this would work - with lots of diagrams!
Non-techs could go here for more articles and presentations.
Contact me and/or subscribe to my blog and/or follow me on Twitter.