Episode 00 --- What Is Muse?
Published: https://youtu.be/fI0TGG1MvUM
Working YouTube title:
What Is Muse? Version Control for Everything
Thumbnail thought:
git was just the beginning.
Target runtime: ~8 minutes
[0:00--0:25] COLD OPEN
[CAMERA --- direct to camera. No intro animation. No music for the first sentence.]
GABRIEL:
Git is probably the most important developer tool of the last twenty years.
And I think one of its fundamental assumptions is wrong.
[beat]
Not bad.
Wrong.
Version control isn't fundamentally about files.
It's about state changing through time.
[TITLE CARD --- very fast]
MUSE
Domain-Agnostic Version Control
[Music enters.]
[0:25--1:05] THE PROBLEM
[CAMERA]
Think about what Git actually sees.
You change a Python function.
Git sees lines.
You rename a symbol across twenty files.
Git sees lines.
You modify four notes in a MIDI composition.
Git sees...
[beat]
...a binary file changed.
The problem isn't that Git is bad at its job.
Git is extraordinarily good at its job.
The problem is that its model of the world stops at files and text.
But the things we create have semantics.
A program isn't fundamentally a collection of lines.
A song isn't a blob of MIDI bytes.
A genome isn't a text file.
And once you recognize that distinction, a much more interesting question appears.
[ON SCREEN]
What would version control look like
if it understood the thing being versioned?
GABRIEL:
That's Muse.
[1:05--1:45] THE THESIS
[SCREEN --- Muse architecture graphic / simple animation]
GABRIEL VO:
Muse is a content-addressed, cryptographically signed, domain-agnostic version control engine for multidimensional state.
And there's a lot packed into that sentence.
At the core, Muse gives us the primitives we expect from version control:
[words appear rapidly]
COMMIT
BRANCH
DIFF
MERGE
HISTORY
PUSH
FETCH
But Muse separates those primitives from the semantics of the thing being versioned.
That means Muse itself doesn't need to know what music is.
Or Python.
Or genomic data.
Instead, we teach Muse a domain.
And this is where things get interesting.
[1:45--2:35] SIX METHODS
[SCREEN --- big numeral]
6
GABRIEL:
A Muse domain implements six protocol methods.
[SCREEN --- preferably real interface/source code rather than a marketing diagram.]
Snapshot.
Diff.
Merge.
Apply.
Drift.
Schema.
[CAMERA]
That's the contract.
Teach Muse how your state space behaves through that interface, and Muse can give that state space version-control semantics.
Not by pretending everything is text.
By operating on the meaningful dimensions of the domain itself.
And that creates some wild possibilities.
[2:35--3:30] SHOW MUSIC
[SCREEN --- MIDI example.]
GABRIEL VO:
Here's a MIDI sequence in Muse.
Suppose I branch it.
On my branch, I change the tempo.
On another branch, Sol changes these notes.
A traditional VCS fundamentally sees two versions of a binary artifact.
Muse's MIDI domain sees something completely different.
[SCREEN --- structured diff.]
It knows that this note changed pitch.
This note moved.
A velocity changed.
And the tempo changed.
These aren't byte offsets.
They're musical operations.
Now merge them.
[TERMINAL --- merge succeeds.]
They modified independent dimensions of the state.
So Muse can reason about the merge semantically.
[CAMERA]
That's the first BOOM.
[3:30--4:25] SHOW CODE
GABRIEL:
Now change the domain.
Same engine.
Different semantics.
[SCREEN --- code repository.]
Muse's Code Domain doesn't have to treat a program as a bag of text files.
It understands symbols.
[rapid real demonstrations]
Ask Muse what changed.
Ask for the history of a symbol.
Rename something.
Detect the refactor.
Ask which symbols are coupled.
Find hotspots.
Calculate blast radius.
Trace dependencies.
[SCREEN --- actual CLI output flashing between examples.]
Git can tell me:
line 47 changed.
Muse can potentially tell me:
this symbol changed, these symbols depend upon it, this refactor moved it here, and this is the semantic blast radius.
[CAMERA]
Same version-control engine.
Completely different state space.
That's the abstraction.
[4:25--5:05] CONTENT ADDRESSING
[SCREEN --- object → SHA-256 → object ID.]
GABRIEL VO:
Underneath all of this, Muse is content-addressed.
Every object has a SHA-256 identity derived from its content.
Snapshots describe state.
Commits form a DAG.
Branches move through that history.
If you've spent time around Git, blockchains, IPFS, Merkle structures, or content-addressed systems, a lot of the underlying philosophy will feel familiar.
But Muse combines content addressing with domain semantics.
The object model answers:
What state existed?
The domain answers:
What does that state mean?
[5:05--5:50] CRYPTOGRAPHIC IDENTITY / AGENTS
[CAMERA]
And then there's identity.
Because something important has changed since Git was designed.
[beat]
The author isn't necessarily human anymore.
[SCREEN --- HUMAN / AGENT → COMMIT.]
Every Muse commit is cryptographically signed with Ed25519.
Humans can have identities.
Agents can have identities.
Commits can carry agent_id and model_id.
Muse uses hierarchical key derivation so identities can originate from a single HD seed and derive domain-specific keypairs.
[CAMERA]
So when an agent modifies state, authorship isn't just a string saying:
Claude <[email protected]>
It's cryptographic provenance.
Who---or what---made this change?
Under which identity?
Using which model?
Can we verify it?
Can we trace its history?
[5:50--6:35] AGENT-NATIVE VERSION CONTROL
[SCREEN --- multiple agents working.]
GABRIEL VO:
And once agents become first-class authors, version control starts acquiring responsibilities that weren't particularly important when repositories were operated primarily by humans.
Agents need to coordinate work.
Claim tasks.
Checkpoint partial state.
Hand work to another agent.
Operate concurrently.
Merge independently generated changes.
Recover when something goes wrong.
Muse has primitives for those problems.
Work queues.
Reservations.
Shelves.
Agent coordination.
CRDT primitives.
And Harmony: Muse's escalating conflict-resolution system for cases where ordinary deterministic merge isn't enough.
[CAMERA]
We're not trying to bolt AI onto Git.
We're asking what version control should look like when humans and autonomous software are peers in the authorship graph.
[6:35--7:15] THE INFINITY MOMENT
[SCREEN --- the ∞ domains mark from the docs.]
GABRIEL:
And this is my favorite number in the Muse documentation.
[point / zoom]
Infinity.
Because MIDI and Code are implementations.
They're not the boundary.
Imagine a domain for:
[visuals appear quickly]
Genomics.
CAD.
Financial models.
Knowledge graphs.
Game state.
Scientific experiments.
Infrastructure.
Agent memory.
Datasets.
[CAMERA]
If a thing has structured state...
If that state changes through time...
And if we can describe the semantics of those changes...
we can ask whether that thing should be a Muse domain.
That's the second BOOM.
[7:15--7:50] THE BIGGER IDEA
[Pacing slows slightly. Camera.]
GABRIEL:
I've spent years thinking about version control.
And eventually I came to believe that we've confused the first wildly successful implementation of an idea with the boundaries of the idea itself.
Version control became synonymous with source code.
But source code is only one kind of state.
[beat]
Muse is an attempt to pull the abstraction up one level.
From files...
to state.
From textual differences...
to semantic differences.
From human authorship...
to cryptographically verifiable human and agent authorship.
From merge conflicts...
to domain-aware reconciliation.
[ON SCREEN]
VERSION CONTROL FOR MULTIDIMENSIONAL STATE
[7:50--8:20] RECEIPTS
[SCREEN --- MuseHub production site, docs, terminal, repo. Rapid but readable.]
GABRIEL VO:
And importantly:
This isn't a pitch deck.
Muse exists.
MuseHub exists.
The platform is running in production.
The protocol exists.
The domains exist.
The CLI exists.
The APIs exist.
The agent tooling exists.
The documentation exists.
[CAMERA]
So we're going to do something much more fun than speculate about it.
We're going to take the entire thing apart.
[8:20--8:45] SERIES PROMISE
[SCREEN --- cards from the docs appearing one at a time.]
GABRIEL VO:
Over this series we're going from the highest-level ideas all the way down to the wire.
Content addressing.
The commit DAG.
Cryptographic identity.
Domain plugins.
Semantic diff.
Merge.
Harmony.
CRDTs.
Agents.
MCP.
The wire protocol.
Security.
And we're going to build things with it.
[CAMERA]
By the end, I don't just want you to know how Muse works.
I want you looking at the systems around you and thinking:
[beat]
Could I version that?
[8:45--9:05] OUT
[Terminal. Empty directory.]
$ mkdir hello-muse
$ cd hello-muse
$ muse init
[ENTER.]
GABRIEL VO:
Next episode, we start here.
No slides.
No architecture diagrams.
We're going to build a Muse repository, tear it open, and see what's actually inside.
[CAMERA.]
Welcome to Muse.
[CUT TO BLACK]
musehub.ai
Production Notes
Episode 00 should feel less like documentation and more like a technical manifesto with receipts. The audience should finish understanding the central abstraction, having seen enough concrete machinery to know this isn't vaporware, and thinking:
Wait. If the abstraction really works, what else can you version with this?
Opening
Don't start with "Hey everyone, Gabriel here." The first ten seconds are precious.
Open immediately with:
Git is probably the most important developer tool of the last twenty years. And I think one of its fundamental assumptions is wrong.
Existing Subnet Show subscribers will recognize Gabriel soon enough.
Show Real Muse Constantly
The episode makes audacious claims. Every 30--60 seconds, quietly provide another receipt:
- actual CLI
- actual source
- actual structured diffs
- actual docs
- actual MuseHub
- actual merge behavior
The viewer should gradually realize:
Holy shit, he actually built this.
Muse Is Not "A Git Replacement"
Avoid framing Muse merely as a Git replacement. That's far too small.
Git provides a familiar coordinate system for explaining the problem, but the thesis is that Git occupies one point in a much larger design space.
Production Style
Don't overproduce it.
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 desired feeling is:
An engineer who has discovered something he desperately wants to show another engineer.
Not a SaaS launch commercial.
The Seed
Don't rush the "Could I version that?" moment.
That's the seed Episode 00 is planting.
The viewer begins the episode asking:
What is Muse?
The viewer should leave asking:
Wait... what could I build with Muse?
That's exactly where Episode 00 should leave them.