**Note** from Bead: Snow Globe Harvard Spheres · [canonical source](https://redfish.acequia.io/guerin/.agents/6a8f0a99-c255-4a5c-9c4a-9097d0ee9cd8/2026-06-11/notes/00-sphere-namespace-survey.md) · session 2026-06-11 · discussion: Talk: Snow Globe Harvard Spheres
What exists around sphere-front-door and sphere-app, and what it's for. Derived from PROPFIND + reading the deployed pages and the local mirror at `sites/harvardviz.live/sphere/`.
## Two origins, one system | Origin | Role | Server | Auth for DAV | |---|---|---|---| | `https://harvardviz.live/sphere/` | Public **front door** (landing cards + legacy/dev copies) | HostGo cPanel (add-on domain of acequia.io) | WebDisk `harvardviz.live:2078`, netrc (`.credentials/_netrc`), DAV root = doc root (no `public_html` prefix) | | `https://redfish.acequia.io/guerin/apps/sphere/` | **Canonical app + data** | Nephele WebDAV node | Bearer `redfish-acequia-jwt.txt`, port 443. Plain-443 PROPFIND on harvardviz.live does not answer; the JSON-listing header is ignored there (static hosting). | The front door's cards all link across to the redfish origin — the app and its mutable state live on the Nephele node, where `.acequia-access.json` sidecars grant anonymous read and the acequia realtime layer is same-origin.
## Front door: `harvardviz.live/sphere/` - `index.html` — "Sphere @ Harvard Cabot Center" landing page; four cards → Controller / Viewer / Admin / QR Page on sphere-app. - `plan.md` (40 KB) — the original CMS design: playlists of equirectangular content (video / image / live web maps), with a Chrome-extension pipeline that detects slippy-map libraries (Leaflet/MapLibre/OL), manipulates them, and **shader-reprojects Web Mercator → equirectangular**, plus static polar overlays beyond ±85°. - `bookmarklet-plan.md` + `bookmarklet/` — successor capture approach to the extension idea. - `sphere-{viewer,controller,admin}.html` — dev copies (Apr 2026) of the pages canonically deployed on redfish. - `index-v1.html`, `player.html`, `playlist-01.html` — first-generation player. - `images/`, `videos/` — local media. `notes.md` — two content leads ("lunar surface", "martin wattenberg").
## Canonical app: `redfish.acequia.io/guerin/apps/sphere/` ``` sphere/ ├── index.html, sphere-controller.html, sphere-viewer.html, sphere-admin.html, sphere-qr.html ├── .acequia-access.json (anon-read sidecar) ├── playlists/ │ ├── active/current.json → { playlistId, currentIndex } (the one source of "what's on") │ ├── approved/<id>.json (earth-systems, harvard-default, human-deep-time, proposal-…) │ ├── proposed/ (controller submissions awaiting admin) │ ├── items/<id>.json (~19 items: stellarium, wind-surface, paleo-earth, air-traffic, │ │ greg-* demos, harvard-yard timelapses…) │ └── items-proposed/ ├── media/ (proposed/, thumbnails/, sphere-qr.png, …) └── maps/equirectangular.jpg ``` **Item schema** (from viewer code): `{ type: "video" | "image" | "iframe", url, title, duration }`. Playlist entries reference items by `itemId` with optional per-entry `duration`.
## How the display pipeline works (from `sphere-viewer.html`) - The viewer is a full-screen page on the sphere's projection PC. Content layers are **200% viewport width** (2:1 equirectangular spanning two screen-widths); image mode uses two side-by-side copies for wraparound. - **Rotation** = `translateX` of the layer by `xRotation` degrees × px-per-degree. No 3D involved — the projection system itself wraps the flat equirect onto the physical sphere. - **Sync**: acequia group `sphere-control` (`https://redfish.acequia.io/acequia.js`); viewer joins with capability `state-leader`. Shared state keys: `playlistId`, `currentIndex`, `xRotation`, `xRotationVelocity`, `viewerOnline`. Controllers (phones, via QR) patch state; viewer applies it; viewer drives auto-advance with a fade transition. - `iframe` items get the same 200%-width container — an embedded page is expected to render its own equirectangular output. **This is the snow-globe insertion point**: a new content type can ship as `type:"iframe"` with zero changes to viewer, controller, or admin.
## Purpose, in one line A consenting-adults CMS for a physical spherical display: anyone with the controller can propose playlists of equirect content, admin approves, the viewer at the sphere plays the approved active playlist, and everyone's phone can spin the globe in realtime.
## Facts that constrain the snow-globe work 1. Output format is a flat **2:1 equirectangular** filling a 200%-width layer; the projection system does the sphere wrap (polar behavior per `plan.md`: content beyond ±85° was handled with static overlays for maps — actual hardware warp unknown, flagged open). 2. The realtime bus already exists (`sphere-control` group) — viewer-position/tracking state can ride the same mechanism. 3. `xRotation` is the established "spin" affordance; for a snow globe it should spin the **model** (turntable), preserving the metaphor and reusing the controller untouched. 4. New content enters through `playlists/items/` + admin approval — the snow-globe viewer becomes available the moment one item JSON points at it.