CORS on the static assets, so the explorer can move under the apex without redistributing die data

[isenbek]

The explorer is the last of the five sites to come under tinymachines.ai, and
it is blocked on one header. Everything below was measured against the live
site on 2026-08-23, not read off the source.

What the move needs

The explorer's front page turned out to be small. app.js pulls in ten
modules totalling 152 KB, all of them ours:

app.js  asm.js  chip-controls.js  chip-nav.js  disasm.js
lab.js  pkg/v6502_wasm.js  program-nav.js  programs.js  renderer.js

and it fetches exactly one data file: layout.bin, 1.5 MB, plus the wasm
bundle the glue loads beside it.

Those last two are the problem, and it is a licensing one rather than a
technical one. layout.bin is die geometry traced from die photographs, and
v6502_wasm_bg.wasm embeds netlist.bin. Both carry CC BY-NC-SA 3.0.
NOTICE.md in this repo records that extern/visual6502 is a submodule
precisely so that this repository does not redistribute NC-SA data, and says
that choice should not be quietly undone. Copying 1.5 MB of die geometry into
tinymachines/public would undo it by accident, which is the way it would
happen.

So the right shape is the one the console and the lab already use: the page
lives under the apex and the chip data stays here. Die Runner fetches this
service's API cross-origin and the Halfwave Lab does too, both of them working
today, because the API sends Access-Control-Allow-Origin: * on purpose.

The ask, which is one header

The static files do not send that header, and they are the ones the explorer
needs.

$ curl -sI -H 'Origin: https://tinymachines.ai' \
    https://6502.tinymachines.ai/app.695d867b.js | grep -i access-control
(nothing)

$ curl -s -o /dev/null -w '%{http_code}' https://6502.tinymachines.ai/app.695d867b.js
200

Serving is fine; the header is absent. The request is:

Access-Control-Allow-Origin on the content-hashed static assets, or at
minimum on layout.bin and pkg/.

https://tinymachines.ai alone would do, and is the narrower answer. * would
match what the API already does and what these files already are, which is
public bytes at a public URL: the header does not make them more readable than
they are, it only stops the browser discarding a response it already fetched.

One thing to watch, because this vhost has already been bitten by it:
a location with any add_header discards every inherited one. The 6502
vhost lost its CSP and HSTS that way once. Whichever location this lands in has
to restate the complete set or declare none.

Why not just proxy it

Because that would make the apex serve the die data, which is the same
redistribution with an extra hop and a less honest audit trail. A reader
fetching layout.bin from 6502.tinymachines.ai is fetching it from the site
that publishes it under those terms. That is worth keeping true.

What happens after

The explorer's front page moves the way the other two did: read at build time,
its twenty tokens remapped onto the house palette, its stylesheet scoped, its
own site-menu.js and version-footer.js dropped because the roof now has
both. Its fetch('layout.bin') becomes an absolute URL to this origin, which
is the same one-line change game.js and the lab each needed and which is
documented at the line in both.

Nothing here changes what this repository serves today. 6502.tinymachines.ai
keeps working exactly as it does, and the explorer keeps living here until
somebody decides otherwise.

Not asked for

• Moving anything in this repository.
• CORS on the HTML pages. Only the assets a page fetches need it.
• Anything to do with the API, which already sends the header.

[isenbek]

This is no longer blocking anything, and it turned out not to need the header.

The explorer moved under the apex on 2026-08-23 and all 18 of its pages serve
from tinymachines.ai/6502/.... There is no cross-origin request to permit,
because there is no cross-origin request: nginx on the apex serves the same
files out of the same directory on the same box.

location /6502/chip/ {
    alias /var/www/6502.tinymachines.ai/current/;
    gzip_static on;
}

location ~ "^/6502/(?<chipasset>(?:pkg/)?[A-Za-z0-9._-]+\.(?:bin|json|wasm))$" {
    alias /var/www/6502.tinymachines.ai/current/$chipasset;
}

The second location is the one that made it work without patching anything.
app.js fetches its data document-relative: it asks for
layout.334bf277.bin, so from a page at /6502/explorer that resolves to
/6502/layout.334bf277.bin. Serving it there means no hash is pinned into the
other repository's build and the two deploys stay independent: the script asks
for whatever name it was built with, and nginx hands back whatever is in
current/.

The licensing concern in this issue is the reason it was done this way rather
than a thing that was worked around. An alias is not a second copy. One
publisher, one set of bytes, a second address the same publisher owns, and
nothing CC BY-NC-SA lands in tinymachines/public.

Two things measured after the move, for the record:

• Every explorer page renders with the die drawing. The regex location is
  narrow on purpose: only those three extensions and one optional pkg/
  segment, so it cannot shadow /6502/games or /6502/lab, which are pages
  and carry no dot.
• Each page has two fewer SVG elements than the original. Those are the octocat
  marks site-nav.js injects, and the roof brings its own navigation.

Worth closing. If CORS on the static assets is still wanted for some other
reason, that is a different ask than this one.