IOTICS | Documentation

Welcome to the IOTICS Developer Hub

Key Concepts

New to IOTICS? Or just after a refresher? This page takes a high level look at some of the key concepts of IOTICS. We are also working on providing in depth white paper style pages on topics, you can find these linked in the description where available.

Brush up on these concepts:

Or take a look at some of our more in depth pages on these concepts:

Digital Twins

What is an IOTICS Digital Twin?

An IOTICS Digital Twin is a virtual representation in IOTICS of a real entity. An entity can be a physical device, a person, a data source, a database, whatever is “real” for the domain.

An IOTICS Digital Twin is made of three parts:

  • Its IOTICS identity
  • Its model representation as a set of metadata records (properties of the twin) and feeds and controls (real time streaming data)
  • Its program or agent to bridge the real and virtual worlds

In practice this means that to create a twin in IOTICS you just:

  • Create its identity
  • Define a model representing the twin properties, feeds and controls
  • Build a program that makes the twin in IOTICS and manages the interaction with the real world

Twin visibility

In IOTICS a host represents the gatekeeper of the twins therein managed. One of the attributes that a twin inherits when created is it’s visibility, which can be PUBLIC or PRIVATE.

A PRIVATE twin is visible only within the host; a public twin is visible in the network.

Searching twins

A twin interested in data from other twins in the network, may search for twins; Currently two search modes are supported: LOCAL and GLOBAL. A LOCAL search is scoped to the host, the searching twin lives in; the search criteria are matched on all twins in that host. A GLOBAL search is broadcasted to the network and matched only on the PUBLIC twins.

The response from each host is delivered to the agent via the search response topic.


Connectors are the generic term we use for applications that manage one or more twin agents. The name is a reference to the fact that these applications typically connect the external world to IOTICS. Designing and building connectors is an important part of IOTICS, and will help you to connect your world easily.

Connectors that normally only ingest data into IOTICS are refered to as integrators or publishers while connectors that only extract data off IOTICS are referred to as followers. Connectors that do both and also apply some transformation logic are addressed loosely as synthesisers.

Difference between connectors and agents

A connector is just the application while an agent has an IOTICS Decentralized Identity.

You may choose to use a single agent identity for a connector that manages multiple twins or choose to use different agent credentials, up to one per twin.

In other words, an agent is a connector with an identity and a connector is one or more agents.

IOTICS sees connectors as agents and the word connector generally refers to an application.


An IOTICS host is the middleware program that acts as the gatekeeper of twins stored therein. In practice the host is the middleware that allows twin programs to interact with other twins in the same host or with twins in other hosts.

Hosts enforces a security context fencing twins from other hosts (PRIVATE twins) or enforces ACLs to allow agents and users to access twins

A host has two interfaces, the IOTICS API used by connectors to interact with host. IOTICS Network API used to interact with the network of hosts.

Users, Agents, and Twin identity

In IOTICS users, agents and twins are uniquely identified using W3C DIDs. It is responsibility of the application owner to make and manage these IDs.

The IOTICS Identity SDK is used to manufacture the IDs and register them in IOTICS so that authentication and authorisation can be achieved.

The decentralised nature of the IOTICS concept and middleware fits very well with the concept of DID and IOTICS Implements the necessary crypto verifications to prove ownership of a private key.

Decentralized Identity Documents

Decentralized Identity Documents (DID) is the way that IOTICS handles credentials, building on W3C's decentralized ID standard.

DIDs are an emerging effort for establishing a standard for self-sovereign digital identities from the W3C Credentials Community Group. They provide entities with a means to self-manage cryptographic key material and other metadata about their identity. This data can be used to authenticate an entity to third parties or to request authorisation for access to a given resource.

You can learn more by reading our Decentralized Identity Documents page.

Security by Design

The secure flow of data has been a guiding principle since the very beginning of IOTICS, and we are proud of our “Security by Design” principles. These principles are:

  • Reduce attack surface
  • Reduce attack vectors
  • Increase resilience and scalability
  • Make provenance verifiable
  • Mitigate against stolen credentials

You can read more about these principles by reading our Security by Design page.


FAIR Data is a set of principles applied to data to make it:

  • Findable: based on common, human readable language that is independent of standards, silos and constraints (semantics)
  • Accessible: both within and without company boundaries, as an overlay on top of existing infrastructure without re-architecting existing systems
  • Interoperable: a safe space for secure and trusted data sharing, creating a true data ecosystem that you control what can and cannot be shared
  • Reusable: integrate data only once then easily share all or part of your data with trusted parties, removing the need for traditional point-to-point integrations and centralised data storage

You can read more about how we use these principles by reading our FAIR Data page.

And you can read about the origins of FAIR data at the Go Fair website.

Updated 2 months ago

Key Concepts

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.