Episode 04 --- Identity Without Passwords
Working YouTube title:
No Passwords. No JWTs. Just a Key.
Thumbnail thought:
the signature IS the login.
Target runtime: ~7:15
[0:00--0:20] COLD OPEN
[CAMERA --- Episode 03's closing shot: a commit record with
agent_id, model_id, and signature all sitting empty.]
GABRIEL:
Three episodes in, and every commit we've looked at has had these three fields blank.
[beat]
Time to fill them in.
[TITLE CARD --- fast]
IDENTITY WITHOUT PASSWORDS
[Music enters.]
[0:20--1:00] THE IDENTITY FILE
[TERMINAL]
$ cat ~/.muse/identity.toml
["localhost:1337"]
type = "human"
handle = "gabriel"
algorithm = "ed25519"
fingerprint = "sha256:d8faf8..."
hd_path = "m/1075233755'/1660078172'/0'/0'/0'/0'"
GABRIEL VO:
Look for a password field.
[beat]
There isn't one. There's no password hash, no API token, no session cookie. Just an algorithm name, a fingerprint, and a derivation path.
[CAMERA]
That's the whole identity. That's genuinely everything Muse knows about who I am.
[1:00--1:45] ONE SEED, MANY KEYS
[SCREEN --- simple diagram: one seed, branching to per-hub keys]
GABRIEL:
One seed --- a BIP-39 mnemonic, sitting in your OS keychain, never written to disk in plain text --- derives a different Ed25519 keypair for every hub you talk to.
[point at the hd_path field]
That path is the derivation recipe. Same seed, different path, different key. localhost gets one key. Staging gets a different one. Production, a third.
[beat]
Compromise one hub's key, and the others are mathematically unrelated. Nothing to reuse.
[CAMERA]
This is hierarchical deterministic key derivation. If you've touched a crypto wallet, this exact mechanism is why one seed phrase can back an unlimited number of addresses.
[1:45--2:30] SIGN A COMMIT
[TERMINAL]
$ muse commit -m "Signed commit" --sign
[SCREEN --- read-commit, side by side with Episode 02's blank version]
{
"signature": "ed25519:UwoPkLuS...",
"signer_public_key": "ed25519:ziza_Za...",
"signer_key_id": "sha256:d8faf8..."
}
GABRIEL VO:
Same three fields. No longer empty.
[beat]
That signature is computed over the commit's own content --- parents, snapshot, message, timestamp, all of it. Change one byte of the commit, and this signature stops matching. It's not attached to the commit. It's a function of the commit.
[2:30--3:05] VERIFY IT
[TERMINAL]
$ muse verify-commit sha256:65b389...
{
"valid": true,
"signer": "gabriel",
"key_id": "sha256:d8faf8..."
}
GABRIEL:
Anyone with the public key can run this. Not just me. Not just MuseHub.
[beat]
There's no server anywhere that has to vouch for this commit. The math either checks out or it doesn't.
[3:05--4:00] AGENT PROVENANCE
[TERMINAL]
$ muse commit -m "Agent commit" --agent-id claude-code --model-id claude-sonnet-5 --sign
{
"author": "gabriel",
"agent_id": "claude-code",
"model_id": "claude-sonnet-5",
"signature": "ed25519:...",
"signer_public_key": "ed25519:..."
}
GABRIEL VO:
author is who's accountable. agent_id and model_id are what
actually wrote the change --- and they ride along with the exact same
real signature as any other commit.
[beat --- pull up a real commit from this show's own repo]
Here's the thing. This isn't a staged example.
{
"message": "fix: --sign help text said HMAC, real signing is Ed25519",
"agent_id": "claude-code",
"model_id": "claude-sonnet-5",
"signature": "ed25519:UwoPkL...",
"valid": true
}
GABRIEL:
That's a real commit, from earlier today, fixing a real bug found while researching this exact episode. Every commit you've seen across this entire series so far was made exactly this way.
[4:00--4:40] WHEN AN AGENT NEEDS ITS OWN KEY
[TERMINAL]
$ muse auth keygen --agent-id ci-bot --hub https://musehub.ai
GABRIEL VO:
--agent-id on a commit is provenance metadata --- a label riding
along with whoever's key actually signed. Sometimes that's enough.
[beat]
But an agent can also get its own HD-derived keypair, distinct from any human's, registered under its own handle. Different agents, different keys, same one-seed derivation underneath.
[CAMERA]
The distinction matters: is this agent acting on someone's behalf, or is it its own accountable identity? Muse supports both, and doesn't force the choice.
[4:40--5:30] MSIGN --- SIGNING THE WIRE, NOT JUST THE COMMIT
[TERMINAL]
$ muse sign header --method POST --path /gabriel/muse/push --hub https://localhost:1337
MSign handle="gabriel" alg="ed25519" ts=1789235952 sig="pqSLGY..."
GABRIEL:
Every single push and fetch this entire series has sent one of these.
[beat]
Not a bearer token. Not a cookie. A fresh Ed25519 signature over the method, the path, and the request body, every single request.
$ muse sign verify --header 'MSign ...' --method POST --url "..."
{ "valid": true, "reason": "ok" }
GABRIEL VO:
MSign is this exact mechanism, at the wire level, every time. We'll open up the full protocol later in the series --- for now, just notice it's the same key, doing the same kind of proof, whether it's signing a commit or authenticating a network request.
[5:30--6:10] WHY NO PASSWORDS
[CAMERA]
A password proves you know a secret. Something that has to be sent, stored, and compared, somewhere, by someone.
[beat]
A signature proves you hold a key --- without ever transmitting it, without any server ever storing anything that could leak.
[ON SCREEN]
NOTHING TO PHISH. NOTHING TO LEAK. NOTHING SHARED, EVER.
Rotate a key. Scope one per hub. Derive a fresh one for a new agent. None of it touches "who you fundamentally are" --- that's still the one seed, sitting in your keychain, that started this whole tree.
[6:10--6:45] THE POINT
[CAMERA]
Go back to Episode 02's blank fields.
[beat]
They weren't blank because signing doesn't exist. They were blank because I hadn't asked for it yet. Every commit in this series since has had it turned on, and you've been looking at real signatures the whole time without me pointing at them.
[ON SCREEN]
HUMANS AND AGENTS. SAME KEYS. SAME PROOF.
[6:45--7:15] OUT
[TERMINAL --- muse domain-info --domain code, the six
dimensions listed]
GABRIEL VO:
We now know how content gets an identity, how history forms a DAG, and how authorship gets proven.
[beat]
We still haven't asked the biggest question in this whole series: how does Muse learn a brand new kind of state well enough to version it at all? Not code. Not MIDI. Something we haven't built yet.
[CAMERA.]
Next episode: six methods, and what they have to teach Muse.
[CUT TO BLACK]
musehub.ai
Production Notes
Episode 04 is where the series pivots from "look what already happened" to "look what's been happening under everything, the whole time." The Agent Provenance section is the emotional peak of the episode --- treat it that way in the edit.
Opening
No abstract security lecture. Open on the literal blank fields from Episode 03 and resolve them one at a time, in the order they'd naturally occur to a viewer: identity file, then signing, then verifying, then agent attribution, then the wire.
The Real-Commit Reveal Is the Whole Episode
The beat where a commit made earlier the same day, fixing a real bug found while researching this exact episode, gets pulled up as Exhibit A --- that's not a nice touch, that's the thesis of the episode made concrete. Don't rush it, and don't let it feel like a gimmick: say plainly that every commit in the series so far has looked like this, and mean it, because it's true.
Precision Matters Here More Than Anywhere Else
This episode is about cryptography and security claims. Every
signature, fingerprint, and header shown must be a real, current
artifact from an actual signed commit or a real muse sign header
invocation --- never a hand-typed placeholder that merely looks
plausible. If a claim about the signing algorithm, the derivation
scheme, or what gets transmitted can't be verified against real
muse verify-commit / muse sign verify output before recording,
cut the claim.
Don't Overclaim the Agent-Key Section
The "when an agent needs its own key" beat should stay honest that
--agent-id on a commit is attribution metadata riding on whichever
key actually signed --- it should not imply every agent commit in this
series used a separate agent-owned key, because it didn't. Save the
full agent-identity story for Episode 13.
The Seed
The viewer arrives thinking:
Okay, cryptographic signing, sure, but that's true of basically every modern system.
They should leave thinking:
Wait --- if identity, content, and history are all just math over bytes... what's actually left that Muse doesn't already know how to version?
That's Episode 05, and the six-method protocol is the answer.