Panes

What a pane is, how a host picks one, and what a page can always expect. Draft, 2026-10-15.

A pane is a view of a thing. The thing is a node in a page's linked data: an island of JSON-LD with an @id and a @type. A host is whatever renders the page: LOSOS, a data wiki, a data browser. This page says what passes between them, so that a pane written for one host works in another. It is written down from running code, LOSOS's shell.js and the datawiki shim, not invented. Where the two differ, the difference is marked.

1. The pane

A pane is a JavaScript object, the default export of an ES module, with these members:

`label`	A string: the name shown on the tab. Required.
`icon`	A short string, usually an emoji, shown before the label. Optional.
`canHandle(subject, store)`	Returns true when the pane wants to render this subject. Required. It may look at anything in the store, not only the type: a schema pane claims any node with a `$schema`, a coin pane claims any node whose bytes it can decode.
`render(subject, store, container, rawData)`	Renders the subject into the container element. Required. Returns nothing the host relies on.

The arguments:

`subject`	A named node, `{ termType: 'NamedNode', value }`, where `value` is the node's `@id` resolved against the page. A fragment such as `#this` or `#me` resolves to the page's own address plus the fragment.
`store`	Answers `store.get(iri)` with the node for that IRI, or null. A host may offer more (LOSOS's LION store does); a pane that wants to run everywhere uses only `get`.
`container`	An empty element the pane owns until the host replaces it.
`rawData`	The island as parsed, before any processing. Optional; a pane falls back to `store.get(subject)`.

export default {
  label: 'coin', icon: '🪙',
  canHandle(subject, store) {
    const node = store.get(subject)
    return !!node && [].concat(node['@type']).includes('TransactionOutput')
  },
  render(subject, store, container, rawData) {
    const node = rawData || store.get(subject)
    container.textContent = `${node.txid}:${node.vout}`
  }
}

SolidOS's pane object (name, icon, label(subject, context) returning a string or null, render(subject, context)) maps onto this: its label is canHandle and label in one. A host may wrap one as the other.

2. Where panes come from

A host finds panes in three places. All three may be present; the order in section 3 says which wins.

local	Panes the page or the host ships: `<script data-pane src="…">` tags (LOSOS), or a directory convention such as `panes/<type>.js` loaded for every `@type` on the page (datawiki). The directory is a registry whose index is the file system.
the node	A node may name its own view: `ui:view` (`http://www.w3.org/ns/ui#view`), a URL of a pane module.
the registry	This site. `reverse-index.json` maps a type IRI to a manifest; the manifest's `pane` is the module's URL and its `schema` the type's JSON Schema. Manifest fields are in the README.

A registry key is a full IRI (urn:solid:Note). A page may type its node with a short name; a host may match on the local name after the last :, / or #. Before asking a registry pane, the host sets $schema on the node from the manifest if the node has none, as autoSchema does, so a schema-driven pane can take it.

A pane module is fetched with import(). Its server must allow cross-origin module loads, or it cannot be used from another site.

3. How a host chooses

For each node on the page, in order; the first step that yields a pane whose canHandle is true wins:

Local panes, each asked with canHandle.
The node's own ui:view, loaded and asked.
The registry, by the node's @type, loaded and asked.

A host that shows one view renders the winner. A host that shows tabs offers every pane that said yes, in that order, and renders the first. It may remember the tab the reader chose, per page.

A canHandle that throws is a no. A pane that fails to load is skipped with a warning; it never stops the page.

Two amendments, from the datawiki, not in LOSOS. (a) When a local pane verifies the node, checking hashes, signatures or bytes, a view the node named for itself is shown after it, never first: a page must not get to choose the thing that checks it. (b) The floor: whatever the three steps yield, the host adds two views last, an outline of the node's properties with links, and the raw JSON. A page with no pane still renders, and what the data says is never hidden behind a view. Hosts are encouraged to adopt both.

4. What a pane may assume, and may not

It may assume the subject's node is in the store and that @id is resolved.
It may not assume the store has anything beyond get, that the page has one island, or that it is the only pane rendered.
It owns the container until the host replaces it, and nothing else in the document.
It must not fetch code the page did not name. Data it fetches is the page's business to allow; a pane that verifies says what it checked and what it only displays.

5. Conformance

A host conforms when it loads panes of the shape in section 1, from at least the local source in section 2, and chooses in the order of section 3. A pane conforms when it has the four members in section 1 and uses only store.get of the store. A registry conforms when its index maps type IRIs to manifests with a pane URL.

Known hosts: LOSOS (local, node, registry; single view or tabs), the datawiki shim (local by directory, node after verifying panes, registry, the floor; tabs). SolidOS's data browser predates this page and uses the older shape in the note above.