UNDER THE HOOD
Governance
Who controls what on the Real Time Web, and what this site is allowed to decide.
Governance, on the Real Time Web, is not a company login. It is the question of who may change a layer without taking the rest.
This site answers that question at the architectural level. It does not run the network.
A network architecture for live bidirectional resource relationships
Understand the idea
Keep data with its source instead of copying it into platforms
Understand the problem
Four independently owned layers, introduced in 2008
Understand the blueprint
Two different jobs
Keep these separate. They are easy to mix up.
This site is a standalone nonprofit explainer. It is not owned by a company. It publishes what the Real Time Web is, why it exists, and Morphic Architecture Design.
An implementation is software someone builds on that architecture. Tools, marketplaces, and services sit there. They are not this site.
Conceptual questions live here. Account, marketplace, and onboarding questions live with whichever implementation a person chooses. Configuration and operations live with that implementation’s own documentation.
Who controls which layer
MAD was introduced in 2008 by Paal Kristian Levang. It splits the stack so a change in one layer does not have to redefine the whole relationship.
L1 · Infrastructure
Hosting, hardware, connectivity
Processing, links, energy, storage where required
The roads
L2 · Network and security
Whoever runs addressing and trust
Identity, authentication, authorization, secure communication
The checkpoint
L3 · Domain and application
Service developer
Services, linking, transformation logic
The shop
L4 · Resource and ownership
The person, machine, or device that owns the resource
Whether the data may be accessed or shared
The goods, and who may use them
- Infrastructure providers control processing, connectivity, and energy.
- Network and security providers manage addressing, identity, and trust. Authentication is optional in the model.
- Service developers own their applications and transformation logic.
- Resource owners control whether a source may be accessed or shared.
The hardware provider, the network operator, the application developer, and the end user do not have to be the same party. That is the design. A heterogeneous network is not controlled by a single entity. It grows as independent participants add their own domains and services.
Who owns the data
Ownership of data at an endpoint is given by the ghostId. Whoever owns the ghostId owns the data at that endpoint.
When a Morphic service is created, the service owner is the primary owner of allocated ghosts. After a user registers and confirms a transfer, the data layer belongs to the user. The application layer stays with the service owner. The service owner may keep a local copy.
Two different people do not open each other’s data because they share an implementation. Read access is a morph. It can be withdrawn. Ownership is a transfer, and a transfer has to be confirmed.
The network does not natively store data. A service may attach a database to its local ghosts. That local copy is the service’s context. It is not a required central store.
Flows
Same owner, two endpoints
You own the lamp ghost. You also own the ghost that represents you inside the scheduler. The ends match. Live data can be consumed.
Or you morph the lamp ghost against the scheduler. That is read access, and you can take it back.
Does not flow
No match, no morph
A neighbor’s lamp is not yours. Sharing an implementation does not open the data. Without ownership or an approved morph, nothing is consumed at the endpoint.
Eternal widespread ownership
The guiding principle is eternal widespread ownership of the Web.
That means the Web should not be permanently captured by a small number of platforms. Ownership, intelligence, and access control should remain distributed among the people and organizations that contribute resources.
This site exists so that sentence has a public home. It is not a marketplace. It is the architecture those marketplaces would have to remain compatible with.
What is not decided here
These questions appear in the source plan. They do not yet have answers.
- Is RTW an open specification?
- Which specifications are currently available?
- How are specifications versioned?
- Where is the technical documentation for an implementation?
Until those are written, this site will not invent a standards body, a voting process, or a contribution workflow. Publishing the architecture is not the same as running a specification program.