FAQ

Answered questions from the RealTimeWeb.org source, plus pending items.

Every FAQ answer is structured as a direct first sentence, a short explanation, and a link to a guide.

General understanding

What is the Real-Time Web?

The Real-Time Web (RTW) is a framework and network architecture for connecting live physical and virtual resources across the Internet.

It allows sensors, actuators, devices, applications, AI agents, services, data sources, and people to participate in the same distributed network. Instead of relying entirely on centralized platforms, copied datasets, and provider-specific APIs, RTW creates direct, bidirectional relationships between authorized network resources.

RTW is designed to give each participating endpoint a persistent network identity while allowing data, access rules, and transformation logic to change dynamically.

In simple terms, the World Wide Web connects documents and information. The Real-Time Web extends this model to connect live data, machines, services, and physical objects.

Is RTW a product, protocol, or network architecture?

RTW is primarily a network architecture and technological framework.

It defines principles and mechanisms for identifying resources, creating bidirectional relationships, exchanging live data, managing access, and coordinating different ownership layers. It is not a single application or standalone product.

Why is a new network architecture needed?

The Internet and the World Wide Web were not originally designed for billions of continuously changing sensors, actuators, autonomous machines, AI agents, and user-controlled data sources.

These resources are commonly connected through cloud platforms, APIs, middleware, and centralized databases, each with its own interfaces and identity systems.

How is RTW different from the World Wide Web?

The World Wide Web is primarily designed around documents and resources that are identified by URLs and retrieved using requests. A hyperlink generally points in one direction.

The Real-Time Web extends this model from static or request-based resources to live, stateful network relationships.

What does bijective network architecture mean?

It means each participating endpoint has one corresponding ghost, and that ghost represents that one endpoint. The relationship is uniquely addressable from both sides.

A conventional hyperlink points one way. The bijective pairing is live and bidirectional. If a ghost could stand for two endpoints at once, ownership of the data would stop being answerable.

What is a real-time data channel?

A data channel is how a linking path collects live sources into a channel of data associated with one user’s ghost in a local service.

The canonical picture is temperature from several makers, gathered for one person. Only data with a valid morphed ghost is received. Both ends need a user who owns the data or has been granted read access.

How is data exchanged between network participants?

Authorized updates can travel along a linking path as they occur. Each service morphs the value into its own local model. The network does not natively store the value.

Data is consumed at an endpoint when the ghosts at the ends are owned by the same user, or the receiver has approved read access. Two different people do not open each other’s data because they share an implementation.

Does RTW require centralized servers or cloud services?

No centralized API or database is required to build RTW services in this model.

Each service works on local structures. A service may attach a database to its local ghosts after it has received a morph. That local copy is optional. The architecture is designed to sit on the existing Internet and to grow as independent domains and services are added.

Is RTW intended to replace the existing Internet?

No. RTW is designed to operate on top of and alongside the existing Internet.

The Internet transports data. The World Wide Web publishes and retrieves information. RTW adds live, bidirectional relationships between physical and virtual resources.

Who created the Real-Time Web?

The Real-Time Web was created by Norwegian technology inventor Paal Kristian Levang. Morphic Architecture Design was first introduced in 2008.

Can anyone implement MAD or RTW?

Yes. MAD and the Real Time Web can have more than one builder.

RealTimeWeb.org is a standalone nonprofit site. It publishes the architecture.

Can other companies build compatible RTW implementations?

Yes. RTW is the architecture. Compatible protocols, tools, services, and commercial products can be built on it. The architecture is shared. The builders can be different.

Is there a reference implementation?

The source names one known pair: a marketplace for domains and participation, and a toolchain used to configure and maintain services.

Architecture

How does the RTW network topology work?

MAD constructs data channels from sources that have been morphed along a linking path. Each service only sees local context. How a value was morphed is unknown outside that service.

There is no centralized API or database required to build RTW services. Data is consumed when the ghosts at the ends are owned by the same user, or the receiver has approved read access. This answer follows draft architecture notes.

How are services, devices and AI agents identified?

They are identified as endpoints with one corresponding ghost. The pairing is bijective and addressable from both sides.

A Morphic service is itself a ghost in the application layer. Ghost id zero is the service. How identifiers are written on the wire is not specified in the current source.

What is an RTW domain?

A domain is an address space you control. It is not a website URL.

If you own the whole stack of a domain, you also control ownership of allocated ghosts for endpoints connecting against that address space. How a public name is registered remains unanswered.

How does RTW reduce unnecessary network traffic?

If nobody is listening, the value does not need to travel. Data stays associated with the resource where it was generated, rather than being copied into a central store that answers whether or not the reading changed.

That is the architectural claim in the draft notes. It is not a congestion-control specification.

What is Ghost Space?

Ghost Space is the shared coordination environment around a network resource. A ghost is a shared-memory representation of one endpoint.

The four layers can observe authorized updates without one party owning the whole stack. Ghost Space is not a chat room. The ghost is tied to a resource, not to a person.

What is a Morphic service?

A Morphic service is an application-layer service on MAD that allocates ghosts for users.

When the service is created, the service owner is primary owner of those ghosts. After a user confirms a transfer, the user owns the data layer. The service owner keeps the application layer and may keep a local copy.

What is the difference between morph and transfer?

Transfer moves ownership of the ghostId after the user confirms. Morph grants read access into another service and can be withdrawn.

Two different people do not open each other’s data because they share an implementation. One of them morphs or transfers.

What is a micropage?

A micropage is a mini description a service owner publishes of the service and its data model.

RTW is protocol independent. The service owner chooses the protocol. If a service does not describe itself, other services have no serious basis for linking to it.

What is a kernelizer?

A kernelizer lets an endpoint receive a self-contained message before the data stream. An empty endpoint can get a program first, then data, without a preinstalled application.

Ownership of the ghost decides which layer can be configured at runtime. This answer follows draft architecture notes.

Is RTW protocol independent?

Yes. The service owner decides their own protocol. How data is structured is described on the micropage.

This site does not publish encodings, command tables, or a required schema language.

Trust, control and security

Who owns data exchanged through RTW?

The data source is owned by the user that controls the endpoint and has registered it against the endpoint ghost. The ghost can be transferred to another person. Morphing the ghost against a secondary service gives read access that the owner can withdraw.

When a Morphic service is created, the service owner is primary owner of allocated ghosts. After registration and confirmation, the data layer belongs to the user; the application layer remains with the service owner.

Where is data stored?

Data is not natively stored in the network. Data is dynamically morphed into local data models along the linking path. A service owner may persist data in the local context they receive. The network natively does not store data, but a service provider may connect a database to local ghosts.

How is access authorized?

Authentication is optional in MAD. An implementation may use any token system that generates a token for identity.

Once a user is registered in an implementation, they may participate in RTW and become members of services by getting access to ghosts.

How can access be revoked?

Morphing a ghost against a secondary service grants read access that the owner can withdraw at any time. A ghost can also be transferred, which is a change of ownership.

Implementations may additionally revoke tokens. Those operational details belong with each implementation, not on this architecture site.

How does RTW protect identities and network resources?

A ghost is a proxy for the network resource, operating in multiple layers, bijectively connected to the endpoint. It provides identity, behavior, and context when an active connection is present.

How does RTW support GDPR and data sovereignty?

The user needs to control who has access to the data source, and data is not persisted in the network space unless the user has agreed to it. Ownership of a ghost and a direct path to the original source lets the user morph the ghost into a secondary service and share data with them.

How can researchers and developers contribute?

Send writing to both review addresses. If it is published, you are credited as the author.

Promotional requests are refused. Ads, business pitches, and tool pitches are blocked, and the sender is not invited again. A formal specification process remains unanswered.

Pending questions

These are listed in the source FAQ plan and do not yet have answers.

Standards and implementation, unanswered:

• Is RTW an open specification?
• Which specifications are currently available?
• How are specifications versioned?
• Where can I find technical documentation?