DOCUMENTATION
How participation works
How identity, domains, ghost ownership, and morphing fit together in MAD. Conceptual only.
RealTimeWeb.org is a standalone nonprofit site. It explains what the Real Time Web is, why it exists, and introduces Morphic Architecture Design (MAD).
The site is independent. The idea can be built by more than one party.
This page maps how identity, a domain, a ghost, and a morph fit together. The path is architectural. Screens and timing are still open.
RTW is the network model. Start with the principles, the layers, and who owns what.
Open related documentation →What happens, in order
1. Read the architecture
Real Time Web is a network concept and architecture. Use this documentation to learn MAD, Ghost Space, and ownership layers. Nothing here creates an account.
2. Establish a network identity
A participant needs an identity so they can be addressed in the network. How identifiers are issued is implementation-specific.
MAD treats the authentication system as optional when constructing an RTW network. Any token system that generates a token for identity can be used.
3. Work inside a domain
If an identified user owns and controls the whole stack of a domain, that user also controls ownership of allocated ghosts for endpoints connecting against that domain address space.
A domain here is an address space, not a marketing website. Whether a public DNS name is required, and how names are registered, is not specified in the current source.
4. Confirm ghost ownership
When a new Morphic service is created, the service owner becomes the primary owner of all ghosts allocated on the service. When a user registers for the service, the service owner transfers the ghostid to the user. When the user confirms ownership, the ghost data layer belongs to the user. The application layer on the ghost still belongs to the service owner. The service owner has access to a local copy of the data.
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.
5. Share live data, then take it back
By morphing the ghost against a secondary service, the owner gives read access to the service provider. The read access can be withdrawn at any time.
Data is not natively stored in the RTW network. It is morphed into local data models along the linking path. For data to be consumed at an endpoint, ownership of sender and receiver ghosts must belong to a user who owns or has read access to the data.
6. Implement independently
RTW is protocol independent: the service owner decides their own protocol. More than one party can build on MAD.
What this site is for
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
Conceptual questions stay on RealTimeWeb.org. The site is a public explanation of the architecture.