gabriel / muse public
issue-100-no-way-to-retrieve-own-public-key.md markdown
57 lines 2.6 KB
Raw
sha256:5650e528954ea615d49212c888ee4901f5c6676a4b8f42feb8f23e576f740118 docs: add local source-of-truth for muse#100 (no way to ret… Sonnet 5 2 days ago

No first-party way to retrieve your own already-registered public key

Background

Surfaced while debugging a muse sign verify command for the Build with Muse episode 04 script. muse sign verify requires --public-key-b64 — the raw base64url Ed25519 public key (no ed25519: prefix) — but the only time that value is ever printed is at muse auth keygen/muse auth register time. If you didn't capture it then, or need it again later (exactly this case: debugging a signing command well after the key was created), there is no command that prints it back to you.

Confirmed no existing path surfaces it:

  • muse auth whoami --json — fingerprint only, no public key.
  • muse auth show --json — fingerprint, algorithm, hd_path, derived paths, AVAX address... no public key.
  • muse auth key list --json — fingerprint, label, timestamps. No public key.
  • muse hub user read <handle> --json — public profile (repos, bio, session credits...). No public key.

The only way to recover it is to re-derive it locally from the keychain mnemonic via resolve_signing_identity() + public_key_to_b64url() — which works, but requires writing a Python snippet against internal modules; there's no first-party CLI surface for it.

Why this matters

The fingerprint (sha256:<hash of the public key>) is one-way — you can't get from a fingerprint back to the public key bytes muse sign verify actually needs. Any workflow that needs to verify an MSign header out-of-band (CI, a pre-receive hook, a third-party tool, or just a human debugging a request by hand, as happened here) needs the actual public key, and today the only source of truth for it is either your own memory of the keygen-time output, or reverse-engineering it from the mnemonic.

Scope

Add a command (or a flag on an existing one) that prints the public key for an already-registered identity:

  • muse auth show --public-key (or a new dedicated field in the existing JSON output) for your own identity.
  • Consider whether the hub should expose a registered public key on a public/authenticated endpoint too (e.g. as part of muse hub user read or a dedicated muse hub user public-key <handle>) — useful for anyone who needs to verify a signature from a different user's identity, not just their own.
  • Decide whether agent identities (--agent-id) need the same lookup (muse auth show --agent-id X --public-key).

Acceptance criteria

  • A documented command prints the exact public key muse sign verify --public-key-b64 expects, for an identity already registered on this machine, without needing to touch internal Python modules or remember keygen-time console output.
File History 1 commit
sha256:5650e528954ea615d49212c888ee4901f5c6676a4b8f42feb8f23e576f740118 docs: add local source-of-truth for muse#100 (no way to ret… Sonnet 5 2 days ago