Upper Name Hierarchy

The federation is held together by consistent use of structured names within name spaces. Here we explain its upper reaches: domains, pages, items and the plugins that interpret them. See also Abstraction of Method

Names are administered by ICANN at the top, the SFW project in the middle, and independent open-source projects along further branches through to the leaves.

We expect each site to have its own (sub)domain name. This makes domain names our ultimate identity system. Its designed for this though sometimes its hard to tell.

Domains should be long-lived but need not live forever. Pages move freely between domains which means the most copied pages could live forever.

Subdomains can be created on-demand through DNS Wildcard addressing and the mechanisms of http virtual hosts. Wiki servers that support this are called wiki farms.

A site is mostly a collection of pages. The mechanics of browsing and rendering the federation adds a few other things like sitemaps and plugins.

Pages are identified by keys called slugs, a normalization of the page's title. A title can change but the page becomes a different page when the title normalizes to a different slug.

Pages are freely copied within the terms of CC-BY-SA license making the federation a "creative commons". Attribution is automatic based on recorded actions that travel with each page.

We expect page names and content to evolve much like words and their definitions in a natural language.

See Special Page Names for naming conventions.

A page contains a list of items called the story and a list of actions that made the story. The actions include a record of a pages travels through the federation.

Items move freely within and among pages. These motions are tracked by actions that don't (yet) record their origins.

An item can be identified by an id assigned at its creation and outliving any particular content within the item. Item ids are not (yet) unique within a page but could be given less permanent aliases to make that so.

An item has a type which names the plugin that can interpret it. Well known types include paragraph, image, and reference.

Plugins are identified by a name drawn from a flat namespace and uniquely defined within a given domain.

The association of item types with plugin names creates some opportunity for reinterpretation (or misinterpretation) since items and plugins don't travel together through the federation.

Plugins can include pages that are made to appear within the page space of the origin server.

A plugin's pages exist to describe its expected use. This documentation often includes sample items preconfigured to make good use of the plugin.

A plugin's pages should describe where and how the open source for a plugin is maintained.

See About Plugins for more about making plugins.

The plugin for each item can make and use various bindings. These include events within the browsing environment and properties made available through the document object model (dom).

Bindings are normally confined to the space and lifetime of the browsing environment. It is possible for a plugin to reach beyond this to, say, talk privately to the origin server.

Plugins that cooperate should do so with bindings managed by an open-source community that makes downloads, installs and version upgrades appropriately easy.

A few model plugins are managed within the core federated wiki software. See Where Numbers Live.

The Data plugin holds datasets in a variety of forms which are made available as reference data for other plugins.

The Method plugin can retrieve named objects from other data and method items and then present calculated results to downstream plugins.

The Rollup plugin retrieves pages and then interprets the items it finds there by orchestrating plugin computations independent of those of normal browsing.

The Logwatch plugin establishes a WebSocket connection with the origin server and interprets an activity stream unique to the two participants.