NITETIME.NET GOPHER

THE KNOWN UNIVERSE
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.
[DIR]READ THE OCTOBER 19 STATION DISPATCH
------------------------------------------------------------------
NITETIME.NET // FEATURE EDITION // OCTOBER 18, 2026
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.
[WEB]OPEN THE WEBSITE
[TXT]PLAIN TEXT EDITION
[DIR]RETURN TO NITETIME.NET
___________________________________________________________________
Gophered by Gophernicus/3.1.1 on Ubuntu/22.04 x86_64

SIGNAL ACTIVE // WISCO 608 // Gateway locked to gopher.nitetime.net