Build With Muse

A video series on Subnet Show about Muse — domain-agnostic version control — and MuseHub, its remote.

Premise: Git occupies one point in a much larger design space. Version control isn't fundamentally about files — it's about state changing through time. Muse generalizes the parts of Git that are actually timeless (content addressing, a commit DAG, branches, merges) and replaces the parts that were only ever about text (diff, merge, "what changed") with a pluggable domain model. Six methods teach Muse an arbitrary state space — code, MIDI, identity graphs, anything.

The series is not a product launch. It's an engineer showing another engineer something he built, episode by episode, receipt by receipt — actual CLI, actual source, actual structured diffs, actual MuseHub, actual merge behavior. See Production Philosophy below.

Season 1

This outline is tentative — episode order and scope may shift as earlier episodes reveal what later ones actually need to cover. Update this table as episodes are added, merged, split, or reordered; treat it as the current plan, not a locked contract.

Arc

Roughly four movements, though the boundaries are soft:

• 00–04 — Foundations. Why Muse exists, what it feels like to use, and the primitives (objects, snapshots, commits, identity) everything else is built from.
• 05–12 — The domain model. The six-method protocol that makes "∞ domains" a real mechanism rather than a slogan, then two proof points (code, music) plus the merge/CRDT machinery underneath.
• 13–19 — Agents and the network. What changes when the primary author is an agent, not a human, and how Muse/MuseHub actually talk over a wire.
• 20–22 — Surface area and payoff. Sharing, security, and a capstone that's supposed to make "you could version that?" land for real.

Repo Structure

Each episode gets its own directory once work on it starts:

build-with-muse/
├── README.md                                 ← this file
└── episode-NN/
    ├── muse-episode-NN-<slug>.md              ← script (see below)
    ├── make-<topic>-episodeNN-demo.sh         ← one or more demo scripts (note: no dash before NN)
    ├── <topic>-episodeNN/                     ← throwaway repo the demo script builds
    └── episode-NN-<slug>.mov                  ← final recorded video, once shot

(Matching episode-00's actual files: muse-episode-00-what-is-muse.md, make-muse-midi-episode00-demo.sh, muse-midi-episode00/, episode-00-what-is-muse.mov.)

Demo directories (<topic>-episodeNN/) are generated fresh by their make-*-demo.sh script every time — they're disposable scratch repos for recording, not hand-maintained content. Re-run the script rather than editing them directly; if a demo needs to change, change the script.

An episode can have more than one demo script if it needs more than one throwaway repo to make its point (episode-00's directory currently has demos for both a Muse/Git comparison and a content-addressing walkthrough, predating this season structure — expect some early cleanup as the season list above solidifies).

Script format

Scripts are timestamped shot lists, not prose essays — see episode-00/muse-episode-00-what-is-muse.md for the reference shape:

• A working title, a thumbnail thought, and a target runtime up top.
• Timestamped section headers (## [0:00–0:25] COLD OPEN) breaking the episode into beats.
• Camera/beat direction in bracketed stage directions ([CAMERA], [beat], [TITLE CARD]) interleaved with GABRIEL: dialogue.
• A production-notes section at the end (visual language, pacing, what the episode is trying to leave the viewer asking next).

Production Philosophy

Carried over from Episode 00's own production notes — these apply to the whole season, not just that episode:

• Show real Muse constantly. The claims are audacious; every 30–60 seconds, back one up with something real — actual CLI output, actual source, actual structured diffs, actual MuseHub, actual merge behavior. The viewer should gradually realize: he actually built this.
• Muse is not "a Git replacement." That framing is too small. Git is a familiar coordinate system for explaining the problem; the thesis is that Git occupies one point in a much larger design space.
• Don't overproduce. Gabriel's face and voice, terminal captures, source code, Muse's existing visual language, a few purpose-built diagrams, and strong editing are enough. The feeling should be an engineer who discovered something he desperately wants to show another engineer — not a SaaS launch commercial.
• Plant the seed, don't rush it. Every episode should leave the viewer asking a sharper question than the one they came in with. Episode 00's version: they arrive asking "What is Muse?" and should leave asking "Wait... what could I build with Muse?"

Status

Update this table as episodes move through the pipeline. "Recorded" means a final .mov exists in the episode's directory, not just that a take was shot.