Wiki pages are passed around the federation as inert specifications. These are brought to life by dynamically loaded javascript modules assembled and interconnected as they are rendered into the dom.
<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vTnBAv2nkSHnEsbi96oyod4rdlI6VoZDy93c0jdwLngiMp8i0GY0JrBPRXZxBvPXuzk4n4_H9GkvRf3/embed?start=true&loop=true&delayms=3000" frameborder="0" width="440" height="600" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>
See JSON Schema
The inert page is encoded into json and often referred to as page json even when that json has been parsed into javascript objects.
Each item of the inert page is identified by type, a string, that identifies a plugin capable of rendering the item into the dom and binding whatever event handlers will be required to bring it to life.
While the inert pages can be fetched from anywhere in the federation, the javascript implementation of plugins is always fetched from the origin. This confines the ultimate responsibility for running code to one location consistent with the trust boundaries respected by the browser.
urbit
EScape Urbit
Urbit: the dial-up of web3? Urbit's landscape feels like a hub for plugins, but largely inert. Of Feb 2022: joining a group via landscape is still minutes on delivery. There's something ringing in my mind about the importance of not wasting computational power. It feels like a catch 22: on the one hand, there are too many people on the network for Urbit to work; on the other, not enough people on the network for the platform to take off...