Gabriel Cardona 🧞‍♂️🔺

vim emulator for Visual Studio Code is a MUST HAVE extension. It adds `vim` keybindings so you can leverage VSCode and all of it's rich extension ecosystem while still rocking `vim` keybindings. https://marketplace.visualstudio.com/items?itemName=vscodevim.vim

I've completed the MVP of 8 out of 22 episodes in the "Build with Muse." series. Once complete, then my intention is to re-record them with higher quality visuals and potentially more examples. I just *really* want to get muse into the hands of developers. So i'm crunching to get this first draft of 'Build with Muse' out so devs can see a deep dive and finally appreciate how amazing muse is. Then once I complete all 22 episodes I'll sweep back over and really polish them. I'm so incredibly stoked with how well muse has turned out. Definitely the best architected system I've ever built. Muse is for sure the best idea I've ever had. ✨🎩 https://musehub.ai/gabriel/build-with-muse

New Build with Muse just dropped. 🎬 **Git sees a delete and an add. Muse sees a rename.** Rename a function? Muse knows it was renamed. Move that function into another file? Muse knows it moved. Rearrange the code without changing its meaning? **Muse knows nothing happened.** No special commands. No annotations. No telling Muse what refactor you performed. Just edit the code and commit. Because once version control understands the structure of what it's versioning, a diff doesn't have to be a wall of + and - anymore. It can tell you what actually happened. This episode gets directly to one of the ideas at the heart of Muse: **A diff is a claim about meaning, not a report about bytes.** Episode 07 — **A Diff That Knows What a Rename Is** Real code. Real refactors. Real output. Next up: if Muse understands changes this well, what happens when it has to **merge** them? https://youtu.be/v3jwUQ1LRzE

New episode of Build with Muse is live! 🎬 **Building a Real Muse Domain** Last episode, we looked at the six-method MuseDomainPlugin protocol. This time, we put the claim to the test. We start with a domain that has never existed in Muse before: a todo list. Nothing fancy. One todo.txt file. One task per line. The point is to choose something deliberately boring so there's nowhere for the architecture to hide. Muse ships a domain scaffold, so we copy it, strip it down, and focus on the only code that actually matters: **the code that teaches Muse what our data means.** For a todo list, that's one idea: Tasks aren't lines of text. They're an unordered, content-addressed **set of tasks**. Once Muse understands that semantic structure, something interesting happens. We initialize the new domain. We commit against it. We branch it. Two people independently add different tasks to the same file. We diff their branches. Then we perform a real three-way merge. The result: **Same file. Two branches. Two independent semantic changes. Zero conflicts.** And there is no todo-specific logic inside Muse's merge engine. The engine didn't change. https://youtu.be/Y0hEE6GVVIM

Episode 05 - The Six Method Protocol is live! Six Methods. Infinite Domains. How can the same version-control engine understand source code, MIDI, chess games, timelines—and domains that haven't even been invented yet? The answer is surprisingly small: • snapshot • diff • merge • drift • apply • schema That's it. Implement the six-method MuseDomainPlugin protocol and Muse gives your domain the DAG, branching, checkout, lineage, history, merge-base finding, and merge machinery for free. But the interesting part is what sits behind those six methods. A code plugin can understand functions, classes, imports, and variables. A MIDI plugin can understand notes, automation curves, and track structure. They can use completely different notions of what a "change" means—trees, sequences, tensors, sets, maps—while the core Muse engine doesn't need to know or care what it's versioning. Same six methods. Wildly different state. This episode goes straight into the real source code and walks through the complete loop: **declare → capture → compare → compare → reconcile → rebuild** https://youtu.be/I2TvV2W3CR0

The muse test suite now consists of 28,592 tests.

Boom! New episode live! No Passwords. No JWTs. Just a Key.

Muse has no password hashes, no session cookies, no API tokens. Every identity — human or AI agent — is an Ed25519 keypair, hierarchically derived from a single BIP-39 seed sitting in your OS keychain. One seed, a different mathematically-unrelated key for every hub. Commits get signed with it. Network requests get signed with it (MSign). Anyone with the public key can verify either, with no server anywhere required to vouch for it. https://youtu.be/TMx5khmjvyQ

muse 0.2.1rc7 is live