UNDER THE HOOD
Bijective network
One endpoint maps to one ghost. The relationship is addressable from both sides.
A conventional hyperlink points one way. The page you link from knows the target. The target does not have to know who pointed at it. That is enough for documents.
The Real Time Web needs a different pairing. Each participating has one corresponding , and that ghost represents that one endpoint. The relationship can be addressed and maintained from both sides. Authorized updates can travel as they occur. The source calls this a .
Bijective, in ordinary language, means a clean one-to-one pairing that reverses. Nothing is left over. If a ghost could stand for two lamps at once, ownership of the data would stop being answerable. If two ghosts stood for one lamp, you would no longer know which stand-in was current.
Why the pairing is bidirectional
In the existing Web, you retrieve a document by asking. For machines that sense and act, asking is the wrong default. A sensor should be able to notify. An actuator should be able to receive. The same relationship has to carry both directions without inventing a new integration for each pairing.
The ghost is the addressable stand-in. What the endpoint reports, the ghost can carry. What the ghost is authorized to receive, the endpoint can act on. The ghost provides identity, behavior, and context when an active connection is present.
The pairing is not a chat room of avatars. People participate in the ecosystem. A person is not a ghost. The ghost is tied to the resource.
Four layers stay independently owned
The pairing sits on Morphic Architecture Design. 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, network and security, domain and application, and resource and ownership can have different owners. The company that hosts a box does not have to own the reading. The person who wrote a scheduler does not have to own the lamp. You do not have to run the network in order to decide who may see the data.
Data still waits for ownership
A bijective pairing is not an open pipe. The linking path can be complex. 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.
There is no centralized API or database required to build RTW services in this model. Each service works on local structures. How data was morphed is unknown outside that service. The network does not natively store the value.
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.
It sits on the existing Internet
The Bijective Network System is described as backward compatible with the Internet we already have. RTW does not replace TCP, and it does not replace the World Wide Web. It adds a live, bidirectional dimension on top of and beside them.
A conventional website can still publish documents. RTW can carry the live channel beside that site. Existing devices and applications can become participants over time. The whole Internet does not have to be rebuilt.
Protocol independence is part of the same idea. The service owner chooses how a service is described. The is where that description lives. This site does not publish command tables or encodings.