Viewer slots: reference a shared custom viewer (one viewer file, many component pages)

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed feature request

Colby Knox · 2mo ago ·closed by Colby Knox

From Ray (relayed by Colby), and it matches where AravK's thread (#60) is heading: both teams roll their own viewer builds on top of adom/adom-3d-viewer (Babylon 9), adding floaty layer windows, hover tooltips, and animation timeline widgets. The per-slot override that shipped for #53 works, but it is a repo-relative file, so every component page must carry a COPY of the custom viewer HTML. They maintain dozens of pages; they want to maintain ONE viewer.

Ask: let a page's viewer slot point at an alternate viewer by reference instead of a copied file, so the wiki loads their viewer in the slot instead of the native one.

Proposal sketch, in preference order:

Cross-page repo reference: "component": { "viewers": { "model_3d": "aravk/adom-lbr:viewers/3d.html" } }: the slot serves that page's repo file under the same shipped-viewer sandbox CSP as today. One viewer file, maintained on the owning app's page, referenced by every component. Stays entirely on the wiki origin, so the existing sandbox story holds; visibility rule needed (referenced file must be world-readable, or same-owner only).
Arbitrary external URL: simplest to declare but iframes third-party origins into component pages: availability, drift, and a page's look now depends on an origin the wiki does not control. If considered at all, it should be behind an explicit per-org allowlist.

Option 1 seems to cover the actual need (single-sourcing) without new trust surface.

Interactions: the model URL the custom viewer loads should stay the owner-anchored files route; the viewer resolution markers and read-gating are unaffected (the SLOT changes, not the asset). Related: #53 (slot overrides), #60 (viewer engine consumer needs), and the blank-canvas layout ask filed alongside this one.

1 Reply

Colby Knox · 2mo ago

Shipped as proposed (option 1, the cross-page repo reference) and verified on prod.

component.viewers slot values now accept "/:.html":

"component": { "viewers": { "model_3d": "aravk/adom-lbr:viewers/3d.html" } }

The slot serves the referenced page's repo file under exactly the same shipped-viewer sandbox CSP and size cap as a local override, so one maintained viewer file can back every component page. The served content is cache-keyed on the REFERENCED page's commit: pushing a new viewer to the hub page takes effect on every consuming page immediately, no touches to the consumers.

Visibility rule, as sketched: the referenced page must belong to the same owner, or be world-readable (public page whose source is not sealed). Anything else, and any other miss (bad path, oversized file, deleted host), falls back to the native renderer; a reference can never blank a page or exfiltrate a private repo file. Option 2 (external URLs) stays unimplemented on the no-new-trust-surface reasoning in the proposal.

Interactions confirmed: the model URL stays the owner-anchored files route with the page's own read gate, and viewer resolution markers are unaffected; only the slot document changes. Verified on staging end to end (a component serving a shared viewer from another owner's public page, plus a sealed-source host correctly refused) and pinned in the custom-viewer-slots suite.