Real Time Web

Technology Introduction


The Real Time Web

The concept of a new web network that can handle IoT and more intelligent services in a way where the network itself can evolve and grow with time, is the holy grail in networking architecture. There are many initiatives both in academia and private research centers that work on to solve some of the challenges the internet is facing today. Like the Solid (inrupt) project led by Sir Time Berners Lee that works on a web for ALL where the ultimate goal is to share information among people with individual control. And then you have the Quic working group initiative that works on HTTP/3 standard to make the internett better suited for IoT and fast data distribution using UDP. Nornir has been working on similar technology for many years with the intent to solve the limitations the web has today. But compared to the project mentioned above our journey had a different starting point and goal. The result is a collective machine network named the Real Time Web.
The concept of creating a new web linking network for machines where machines are placed in the center of the architecture and a network topology created to support a machine society is what Real Time Web is all about. Real Time Web is a heterogeneous collective network for autonomous machines, written in a language humans can understand.


HIVE Collective

The concept of HIVE Mind is not new, but is used to explain how the Real Time Web works. You may have seen the Star Trek series about the BORG species, which basically is a machine society that each individual is part of a larger collective and that the collective makes each of the individuals stronger and more intellectual since it has a direct link with the Hive Mind.
The Real Time Web works in a similar way. Synx HIVE is a collection of tools that enables developers to use the same principles and make single network resources to become super intelligent since they can join the collective and jump between various morphic services. How intelligent a robot or a client can be is only limited to his own physical abilities.
Let say you own a temperature sensor that provides temperature reading outside your house. The sensor only transmits celsius reading but it can be used to do super intelligent things. First it provides specific temperature capturing (data) at your location that hundreds of applications in the collective can make use of in various contexts. Second you can add this sensor to a secondary service just by a simple command and the sensor inherits properties of that service as well. Let’s say that the secondary service is a light control service that can be used to turn on/off your light in your apartment.
Now, by adding the temperature sensor to this service the sensor becomes a light switch. The service provider of the switch service now gets access to the sensor data and can trigger ”lights on” when temperature hits 20 degree, and “lights off” if the temperature hits 15 degree. Any network resource object works the same way, joining it to a secondary service makes that object change behaviour and inherit intelligence from the service you choose it to become. Simple IoT objects may be used for anything you want it to be and the intelligence is inherited at runtime.
Imagine how the temperature sensor can be used to turn on the coffee machine, lock doors, regulate heat on remote systems and much much more. The only thing that limits the behavior of the sensor is its physical properties which in this case only uses one data element (temperature). Imagine what you could do if you had a robot with arms and legs… 🤖 🦾
When more and more services are created the collective becomes more intelligent and more reliable. Any device gets its functionality from the collective and the behavior can change based on which context (morphic service) the device is running.


Bidirectional Links

Linking in the Real Time Web (RTW) differs from traditional Linked Data. To understand RTW linking and why the network has been designed like this we have to understand the concept of Data, and our definition of data.

If you ask Wikipedia about Data you’ll get “Data are characteristics or information, usually numerical, that are collected through observation”. This is a misconception. Machines look at data and information differently. Information consists of structured historical data, while data is the value content of the information before it becomes historical. Technically speaking the data exists only before it has been stored into a database or filesystem, then it becomes information.
To understand machine networks like RTW we will need to distinguish data from information. Machines don’t really care about information and don’t need information to live among humans. Humans however are dependent on information, the human brain cannot process data fast enough and need to structure data into information and do lookups when needed. Normally before and after dinner using the World Wide Web.

A machine network is about distributing fresh data in a network to other machines that consume and act on the data. This is done in real time. The same data can be used differently and it can trigger different processes. Data is normally generated by IoT devices that transform sensor readings into alphanumeric data for distribution.
How and what these data will be used for is unknown, and the data may change context and transform into knowledge differently while it traverses through the network value chains. Some data may end up being important for millions of users while other data may not be used at all. The only thing that we know is that billions of data packages will end up in millions of different use cases in the network every day.
Real Time Web used links to address transformation of data in the network. Each service provider may find and link to a data source offered by another service provider. The link is structured like a sentence with a subject, predicate and an object. Following the Semantic Web standard.
For a normal person that is not into Semantic Web, the triplet notation is analogous to how you build up a sentence using normal vocabulary. The predicate is like a verb, it is something you do; like “I’m driving a car” or “you are reading a newspaper”, where the verb is “driving” or “reading”. In machine language this “verb” is called predicate.

So using links in RTW is straightforward. You create a service name which is the “Subject” which includes the data model. Then you link to another service provider data element which becomes the target data source (object). If you need to do something with the data you add a predicate to the link. A predicate can be done using an inline script or a software agent. The goal is always to transform data to fit your local data structure so if someone wants to link to your local data source they don’t have to worry about inconsistent data in the value chain.
Bidirectional linking works on the same linking path but in the opposite direction. Is only limited to commands being sent from the owner of the primary service to a secondary service that offers intelligent services that act on the command.



Morphic Microservices

The name “Morphic” is inherited from the fields in biology that explain morphogenesis and organizing fields. Technically speaking it means that a system can inherit behaviour and logic based on tuning in the right data channel. It’s like tuning in a radio channel when you want to listen to music and change this channel to another frequency if you want to listen to something else.
Morphic services differ from traditional microservices in many ways. One key difference is the use of Morphic Architecture Design (MAD), a multi layer architecture design method invented by our founders Paal Kristian Levang and Henrik Silverkant and has been used to define the Synx tools (Synx HIVE) and how they operate. Traditional microservice operates in one layer of existence, “what you see is what you get”. The entity that wants to send or receive data from a microservice needs to know the data structure in advance so a programming interface (API) can be implemented to secure the communication. Morphic service does not use API implementation and the data structure may change at runtime while clients have an active connection. Morphic service is designed to support semantic web to create AI collective and the bidirectional linking is supported by a distributed operating system named Synx BIOS. Synx BIOS segregates the communication layers and provides different access control on network resources, domains and morphic services. There are no code libraries or installation needed on network resources when communicating with the collective. Synx enables both stateful and stateless HTTP/HTTPS/Websocket communication over TCP.


Network Ghosts

Real Time Web works much the same way as the World Wide Web and is backward compatible with current TCP stack. But, there are some slight differences.

First of all the lower communication stack levels (ISO layers) have been enhanced by SynxBIOS which can execute and send data up and down the layers and segregate the access control. Second, the connection point of a client (network resources) that connects to a specific IP address and URI is always connected against his ghost. So instead of establishing a communication against a service provider platform, or web server with session handling, all this has been taken care of by the SynxBIOS. The ghost memory entity acts as a remote proxy for the connected client and is created at runtime on connection and it disappears on deconnection.

The footprint is small since the ghost only exists when there is some data that will be transferred to and from the client that has been authenticated, and the data structure is inherited at runtime. The connection between the client and his ghost can be stateless, stateful or combination of these. The client can also use HTTP, HTTPS, socket or any other combination while communicating.

Communication against a ghost entity is protocol independent and new protocols can be added. The ghost entity can also change behavior and data structure while on active communication, meaning the data structure is not fixed and can be altered by the service provider.

For more information on how to communicate with HIVE collectives visit

Real Time Web

Ghost VS digital Twin

All network resources like clients, servers, gateways, IoT-objects, mobile applications or anything that wants to communicate with the HIVE will always connect against his unique ghost. Ghosts differ from the concept of Digital Twins in some areas. Ghost can be used to create digital twin services, but also extend the digital twin concept a step further. Ghost operates in multiple layers in the communication stack. So the top layer (data layer) may work similar to a traditional digital twin network. But the ghost can also gain access to the lower stack layer and may receive events up and down these layers at runtime. The other layers provide contextual data to players in other areas of the network ecosystem. If you look at a communication network ecosystem you find several “passive” players like hosting providers who maintain the physical hardware like servers, network routers and domain name services. Then you have security providers that do all sorts of monitoring, blockchains and encryption algorithms in the network. Then you have the application and service provider who create web services and applications that can be accessible and addressed via domain names (URL). Synx technology is designed to be an open decentralized machine p2p network. So to be able to secure data between two unique endpoints, other players in the network ecosystem cannot access the data layer, events up and down the stack layers controlled by Synx BIOS (network operating system) need to provide a method that legally can intercept the communication. Ex. two clients are sending messages to each other using a service that belongs to a service provider. The service provider can anytime send a Synx command to kill the active connection on one or both of the clients end points. So even in a p2p network (no server or middleware logic) the client can be disconnected from using a specific service. Synx BIOS also supports moving ownership of ghosts and network resources, handles read access and moves ghosts between services dynamically at runtime. Ghost follows the user’s signature and can change the behaviour of the “digital twin” dynamically. This way a ghost can gain full ownership and network accessibility. The network becomes more secure and robust for changes and ownership on resources can be moved around in the open heterogeneous network and gain (allocate) cpu and memory resources from players with lower layer access levels.