Real Time Web

Technology Introduction

REAL TIME WEB

Key Features

Synx is the technology behind Real Time Web. Synx enables linked data distribution in a heterogeneous network (open network). The network is self scaled and designed to establish fast communication between endpoints (network resources) using a collective of morphic services that are linked together.

The network becomes intelligent with more services added to the linking paths. We made some tools to help developer explore the Real Time Web. We have bundled and named our tools for Synx HIVE. An implementation of Synx HIVE can be found at Cioty.com where you can trial and test how to build a RTW morphic service yourselves. We have also made a developer kit for IoT developers to explore the opportunity using Synx HIVE The kit can be purchased at nornir.shop and is a nice way to get introduced to Real Time Web development.

Synx Hive is solving some of the key technical challenges organizations face when building new Internet of Things applications, including:

Establish cross platform communication with just a click
Building reliable and scalable business critical IoT applications
Fast real time data distribution for entire value chain
Lower developer and maintenance cost for hardware and software projects
Dynamical change and update to services without downtime
Distributed database and supporting blockchain (optional)

REAL TIME WEB

Real Time Web Overview

REAL TIME WEB

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 microservices differ from traditional microservices in many ways. One key difference is use of multiple layer architecture. 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 machine 2 machine collective and the linking support the triplet model topology.

The semantic web notation has not been fully implemented into Synx today, but Nornir is planning to implement this in the next version of Synx Hive.

REAL TIME WEB

Ghost Communication

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 is a kernel that can execute data up and down the layers and segregate the access control.
Second, the connection point of clients and network resources that connects to specific IP addresses and URI is using a ghost micro memory container which is part of the communication stack.

So instead of establishing a communication against a service provider platform or using server logic 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 and documentation visit SynxHive.com.

REAL TIME WEB

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.

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 transforms 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. How to design this network then?

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 model 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 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.

REAL TIME WEB

Intelligent Linking Path

Figure 1

When various data providers link each other a complex linking path will start to emerge in the network. For each of the nodes in the figure above represent a service provider (URI) and the lines illustrate the links.

Figure 2

Each of the nodes represent a subject with data offerings and can become searchable online. When a client connects (illustrated as object A) to the connection point (URI) the client is identified and a ghost entity is created by SynxBIOS. See figure 2.

Figure 3

A morphic channel is constructed and replicates the transformation (predicates) of the data in the network by following the links. The ghost entity is now ready to receive real time data from the network.

Figure 4

Another client connects to the network (illustrated as object B), undergoing the same initialisations as Object A above.

Figure 5

The difference is that ghost entities to Object follow a different linking path based on how data providers have linked the data together.

Figure 6

Now how data is distributed in the network depends on the access level. Data layer in the communication stack is separated from the application layer and domain layer.

If object B and object A have the right credentials (user access) to access the data from the network, only then data is sent to the ghost entities for processing which bypass the data to his client. Data between object A and object B can be transformed differently by the ghost entity. When the client disconnects the ghost disappears from the network.

The Real Time Web uses SynxBIOS that offer event driven distribution of data and multi layer communication stack. This enables the network to be dynamic. While clients receive data from the network the linking and service model can be changed without the client to be disconnected. Is also possible for the service provider to send a Synx command to the network kernel and force disconnection for clients that use his service. This may be useful when the client is a payable customer and is using a p2p service from the service provider.

The service providers in the linking path may not access the data that is transferred between object A and object B unless they are granted access. This means that HIVE collective (Real Time Web) is GDPR compliant.

REAL TIME WEB

Web BIOS

SynxBIOS is a distributed networking kernel that is used to provide identity, authentication and give access control in heterogeneous networks.

SynxBIOS offers a series of commands that you can send into the RTW network to change the dynamics of the network characteristics. These commands can be done at runtime and do not affect the data layer performance. There are 4 levels of command that can be used based on your access level. For more detailed information about SynxBIOS please visit synxhive.com.

Matrix Overview

Stack Level	Stack Layer	Ghost Object	Access Level	Connectivity
1	Data	C	Basic Synx commands only: Register User; Give ownership; Accept Ownership etc.	Support HTTP, HTTPS and Socket communication. Connection role both client and server. Support both stateful and stateless communication
2	Application	T	Extended Synx commands: Register subdomain/service; Setup Data Link and more	Access trough domain registrar tool like cioty.com (which is a SynxHIVE controlled by Nornir)
3	Domain	P	Root Domain owner and super user on private HIVE	Access granted by Root to map IP adresse and basic HIVE configuration. Command line option only
4	Physical	A	Root access and root domain registrar for private and public HIVE	Access by installation and environment control (network, firewall, routers etc). Source repository
5	Protected	A	SynxPass CMD; backdoor root ghost access (anti objects)	Can only be access by Agent Smith

Based on your access level you are entitled to changing properties to your ghost entities. The distribution of the commands is done asynchronously in the network. In the table above you see each layer of the stack and how they correlate with the ghost entity. The ghost has a different role in the network based on which layer is accessing the entity.

In figure 6 you see user1 perspective receiving data from a service urlA.com. The user ghost controls the linking path for the user and the user is unknown to the providers (urlD,urlB,urlC) in the linking path. The user can only access the input and output of the service he chooses to connect to.

In figure 7 a second user2 is connecting to the same urlA service. User2 can have different outcomes from his ghost entity than user1. The data structure is the same but data values that are offered by the data provider urlA.com can have a different origin. For example user1 may have his data in another language than user2, but the semantics on the data is the same.

The service providers have access to stack level 2 (application) and additional Synx commands. Typical commands like setting up links and adding predicates to manipulate the target data to fit local data structure. After several links and multiple services in the linking path the network gets aware of his collective intelligence. From a user perspective the benefit is to tap into the right service to access real time data based on personalized context when needed.

This network is useful for intelligent robots or machines to get localized contextual data and to change the context at runtime without dealing with programmable interfaces and databases. Each of the service providers in the linking path also keep their predicates and data algorithm unexposed to each other. Which is generally good for business and innovation.

Real Time Web

Hive Mind Architecture

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.

Synx enables the same principles and enables 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 properties.

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 data capturing 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 to the network and the sensor inherits properties of that service as well. Let’s say that the service is your 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.

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. 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.

REAL TIME WEB

Real Time Web for IoT

The Internet of things (IoT) can be any smart object that is equipped with a sensor or actuator. Using Synx Hive to administer IoT simplifies the development and maintenance, and drastically reduces the cost.

You can go to a local store, buy a smart sofa that is equipped with a movement sensor. Then you search for usable services online and new services may be developed in the future. When you find a suitable service, let say you find a remote control of your television service, you can add your sofa to this service. The integration is done by the service providers setting up a link to your sofa manufacturer RTW home page. This is done in seconds.

Now your sofa has inherited remote control properties and you can use your body to trigger the movement sensor to step up and down channels on your television. You can also add your sofa to the switch service and now you can use your sofa to turn on/off your lights.

One of the main advantages of Synx technology and what makes it brutal energy effective is that data is personalized. So if Ikea is selling 1,000 individual sofas to 1,000 different families and each of these families uses different online services, the data only communicates between the physical sofa to the specific app that belongs to the owner of the sofa. So who you are, determines what kind of data you can receive or send.

And what is even more amazing is that the service providers that transform the data in the collective don’t need to have access to your data. So this means that no one beside ourselves knows which channel is being watched. Unless you add your television to a “watch my channel” service…