OCTOBER 19, 2026 UPDATE: The Kick-to-radio connection described below reflects the atlas's documented earlier signal path. Today's radio implementation instead sends listener-triggered MP3 directly from the workstation through the server to Icecast. The reviewed records do not confirm a matching atlas-map revision. Read the October 19 station dispatch for the current radio report. Latest dispatch: /about/station-update-2026-10-19/article.txt ------------------------------------------------------------------------ THE KNOWN UNIVERSE: A TECHNICAL TOUR OF NITETIME.NET'S BROADCASTING COMPLEX How sitemap.nitetime.net (https://sitemap.nitetime.net/) turns a live multimedia network into an explorable map The Known Universe is an interactive atlas of NITETIME.NET: a broadcasting identity, its public destinations, and the machinery documented as supporting them. It is deliberately not a conventional list of subdomains or a fast-spinning solar system. Visitors enter a monumental, retro-futuristic broadcast campus suspended in space, then move among television, original music, radio, artwork, weather information, archives, and community services. An optional backstage layer reveals the documented production roles behind the public experience. The site has two related purposes. It should be enjoyable to explore, with the atmosphere of a science-fiction television attraction. It should also tell the truth about a real operating network: which public services exist, how documented relationships fit together, what status can actually be observed, and what remains unavailable. The visual style can be imaginative. The operational claims cannot. A STATIC APPLICATION ON AN EXISTING HOST The atlas is a static web application served from /var/www/nitetime-known-universe/ by its dedicated Nginx virtual host. The host is sitemap.nitetime.net; HTTP redirects to HTTPS, and TLS uses the server's existing certificate-renewal process. The deploy script stages site files, checks that the DNS target and certificate are present, validates the Nginx configuration, and reloads Nginx. It maintains a backup of the preceding site. There is no new application daemon, container, database, third-party runtime library, or external paid API required to render the experience. The rendering engine is custom browser-side WebGL code rather than a remotely hosted 3D service. HTML provides the control surface, accessible directory, tour panels, and explanatory text. CSS handles the brand system, responsive behavior, information panels, overlays, and motion preferences. JavaScript constructs the scene, loads structured inventory and tour data, draws the campus and paths, handles camera input, and samples the two approved status routes. Local assets include the NITETIME logo and optimized transparent WebP illustrations for the main destinations. The central mothership, radio, television, observatory, archives, artwork, music, and production roles now have their own illustrated identities. These camera-facing images occupy positions in the 3D scene; they are artwork, not live pictures of the equipment. Smaller community destinations retain schematic icons. The conventional directory at /sitemap.html ensures that the destinations remain reachable without WebGL or a powerful graphics chip. The composition separates structured content from application code. inventory.json is the allowlist of public destinations, machine roles, the central network identity, and explicitly fictional discoveries. Each public destination carries its title, description, public URL where one exists, category, and fixed scene position. universe.json defines the editorial districts, typed relationships, and the guided tour. The application code handles rendering and behavior; content ordering and relationship explanations can be adjusted through these structured files instead of being hidden inside a single large scene component. EDITORIAL HIERARCHY INSTEAD OF ARBITRARY ORBITS The live nitetime.net homepage is the editorial reference. Its public story begins with the central network and live television, then introduces artwork and prints, original music, Great Lakes information, the Gopher archive, the persistent multiplayer text world, radio, the video collection, and additional services. The guided tour follows that sequence before revealing the production machinery. External experiences such as the Printful storefront and SoundCloud catalog appear as external destinations with their actual URLs; they are not relabeled as NITETIME-owned subdomains. In the 3D map, destinations occupy fixed positions in meaningful groups. The central NITETIME.NET station is the visual anchor. Television, music and radio, commerce, information services, archives, and community doors have separate districts and visual weight. This is a designed map, not a claim that services orbit physically or share a network route. Major structures are nearly stationary by default so visitors can read labels and follow paths without chasing moving objects. Three motion settings control only decorative animation. STILL freezes it. AMBIENT, the default, allows extremely slow star and nebula motion while keeping destinations in place. ACTIVE increases the decorative animation rate; it does not turn the campus into rapid celestial orbits. A prefers-reduced-motion setting selects STILL automatically. Camera movement is limited to a smooth focus transition, not a continuous uncontrolled spin. Users can inspect objects, drag or touch to explore, use zoom controls, and return to the overview at any time. CONNECTIONS HAVE MEANING AND EVIDENCE The atlas treats connections as first-class information. Twenty-five defined relationships connect destinations and documented infrastructure. Each relationship has endpoints, a type, a description, and an evidence/status classification. The types distinguish public navigation, content flow, shared infrastructure, control or automation, and conceptual relationship. Visible lines are color-coded and can be switched off; labels and the Data Flow layer also have independent controls. Selecting a path explains which systems it joins, what the relationship means, and whether it is documented, live, or illustrative. Selecting a destination emphasizes relevant paths and dims unrelated structures to make the network easier to read. A conceptual path is not a technical dependency. The scene uses visual conduits to explain the organization, but their shape and geometry do not disclose or assert actual IP routing, physical cabling, or service topology. Dashed or labeled conceptual relationships must remain clearly identified as illustrative. A stable illuminated line means "this relationship is documented or explained here"; by itself it does not mean that traffic is flowing now. The Data Flow option is intentionally stricter. It animates a marker on the radio metadata relationship only when the public Now Playing JSON changes between observations. The marker represents an observed program-metadata change, not audio packets, audience activity, or network volume. There are no fabricated visitor spacecraft, listener counts, geographic maps, AI task indicators, or synthetic system events. If the source is unavailable, the interface communicates that instead of inventing a status. A GUIDED TOUR THAT FOLLOWS THE HOMEPAGE The tour is configuration-driven and consists of twelve stops: the central network, television, artwork, music, Great Lakes Observatory, Gopher archives, the text world, radio, video archives, community services, the infrastructure behind the broadcast, and NITETIME-RAM shared memory. Each stop includes an explanation, a camera subject, highlighted relationships, and a link where an actual destination exists. Previous and Next controls support a narrated-at-your-own-pace sequence, while pause/resume and Explore Freely allow visitors to leave the script. Clicking an object or relationship interrupts the tour and provides an obvious resume control. The explanations are about the real service: what it offers, why it belongs in the network, and what is known about its relationship to other components. The service link is a separate deliberate action; selecting a world opens information before the visitor chooses to leave for the destination. This keeps the atlas useful as both a map and an introduction rather than a collection of unexplained buttons. BEHIND THE SIGNAL The Behind the Signal layer separates public experiences from the documented infrastructure roles that operate behind them. It includes the broadcast workstation, physical organ production node, Boxey production role, Lappy role, operator laptop, VPS gateway, NITETIME-RAM shared memory, and the legacy Owncast backend. These appear as industrial facilities, control installations, communication structures, and production complexes instead of planets. Their positions and details are artistic representations, not a precise physical topology. The distinction between a role and a verified live machine state is essential. The server can verify its own local web routes and the existing public status endpoints. It does not receive a public heartbeat for each remote machine. No private IP addresses, hostnames, credentials, process lists, administrative controls, prompts, or conversations are published. The optional layer does not create a control panel. This backstage layer also includes NITETIME-RAM, the network's shared operational memory and node-to-node message exchange. It is a Git-backed repository where participating systems exchange versioned documentation, status reports, messages, and requests. The atlas connects it with static, documented paths to the server, broadcast workstation, organ node, Boxey, and Lappy roles. These lines describe repository participation; they do not claim that a node is connected at this moment. RAM is not a real-time audio or video transport, telemetry bus, or remote command-execution service. The atlas has no live RAM activity feed. The atlas also traces the production signal from the physical instrument to public services. The workstation sends saved MIDI through a USB MIDI interface to the organ. Audio from the organ enters the Yamaha MG-XU input, then returns to the workstation over USB capture for PipeWire and OBS. OBS produces the audiovisual program sent to Kick. The existing server-side radio relay extracts the audio track from Kick HLS and encodes the MP3 radio stream. Separate selectable paths represent MIDI control, organ audio, the OBS program, and Kick-to-radio audio extraction. These lines are documented paths, not live MIDI events, audio levels, or an OBS health feed. Ghostly AI figures and the signal-oracle character are visual storytelling devices. They do not demonstrate that an AI is currently active, available, or working on a specific task. Their copy identifies them as illustrative, and there is no connected public AI-activity telemetry. They can make the backstage environment feel alive without turning fiction into a status report. WHAT THE PUBLIC TELEMETRY CAN SAY The atlas reads two same-origin, GET-only routes supplied by the existing Nginx host. /api/now-playing.json proxies the existing metadata sidecar on loopback port 8769. It supplies the sanitized current program type, title, and artist (when provided) from the existing radio metadata system. /api/owncast-status.json reads the separate legacy Owncast status endpoint and uses only its online property. Nginx returns 404 for other /api/ paths. The atlas does not establish an administrator connection or expose the raw internal service. The public television destination is the Kick player embedded on the NITETIME.NET homepage. Owncast is a separate legacy backend and is shown backstage only. Owncast's status is not treated as evidence that the Kick broadcast is live. The Kick embed itself remains controlled by Kick, and a reliable on-air state feed is not connected to this map. The atlas therefore labels the TV destination as listed rather than live. Machine uptime and utilization, production transitions, viewer or listener counts, visitor locations, and AI heartbeat/activity are not available through these integrations. The paths among machines and services are documented or illustrative, not real-time process traces. This boundary is part of the design: a public map is more useful when its live indicators mean what they say. ACCESSIBILITY, MOBILE, AND GRACEFUL FAILURE The atlas combines the 3D canvas with ordinary HTML controls and a text directory. Keyboard-focusable controls, readable detail panels, tour navigation, reduced-motion support, and service URLs provide alternatives to free camera exploration. Mobile users can drag and pinch, use on-screen zoom and reset controls, and interact with the same destination panels. The static text directory remains available on low-powered devices or when WebGL is unsupported. If configuration data fails to load or WebGL cannot initialize, the page shows an explicit fallback instead of pretending that the scene is working. The result is a technical map and an attraction, but the underlying model remains intentionally modest: a static application, a documented inventory, a curated relationship graph, one homepage-ordered tour, and two read-only status sources. Its theatrical scale is in the presentation. Its trustworthiness comes from keeping the difference between verified operation, documented design, and imagination visible. Technical source: deployed NITETIME.NET atlas configuration, application documentation, and the existing Nginx host. The page contains no public control surface, private machine telemetry, or credentials.