Jeff Dickey - Mise, HK, Fnox, and Aube

Speaker A: Seeing developers work with Node, the most common thing for the last two decades almost has been uh, forgetting to run NPM install after pulling down a branch. Uh, even agents don't do it right. Uh, and this is ridiculous. I'm sorry, like this should have been fixed years ago, but I'm fixing it now, um, with just like having that behavior.

Speaker B: Hello. Welcome to DevTools FM. This is a podcast about developer tools and the people who make them. I'm Andrew and this is my co host Justin.

Speaker C: Hey everyone. Uh, we're really excited to have Jeff, uh, Dicke back on with us. So Jeff, uh, we had you on what simultaneously feels like uh, forever ago and then not so long ago. Um, and it's so great to have you back. You are our second episode recently of like someone coming back who is like releasing a new version of thing or doing a new thing. So excited to um, have this new series. So you are starting a new company and we're so excited to talk about that. Uh, and you're building some new tools. Uh, so before we dive into all that stuff, could you give our guests a refresher, just like do a reintroduction of like who you are and what you do?

Speaker A: Sure, yeah. So my name is Jeff Dick. I've been like making dev tools and clis for a very long time now. Um, my first job was, was writing the Heroku CLI. That was almost 13 years ago now. Um, and ever since then I just really have loved making dev tools and clis. It's just been huge passion of mine. And so after that I've gone to do that at ah, Facebook, at ah, Amazon most recently Figma. Um, and yeah, um, done a lot of open source, you know. Um, my most famous product is, is Me's, which I'm sure a lot of listeners will know. Um, and been working that for about three years now. It's been, been a huge success, a lot of fun to write. Um, and yeah, like you said, I. About three weeks ago I made the decision to sort of find a way I can do this full time because you know, open source has always been a part time thing for me. Um, but uh, I love it so much. I like gotta find some way to do this all day.

Speaker B: Yeah. So let's jump right in right there. Uh, can you tell us the name of the new company and like what kind of like finally pushed you over the edge of like I'm gonna stop being the CLI guy at a company and just try to do this on my own.

Speaker A: Yeah. So the name of the company is on dev. Uh, and it's a lot of that's just the domain I got, I got the domain en dev. Um, but I also like I had a bot that was me's on dev. So it was like me's in dev. Um, because I've always made a lot of tools and so the pattern's always I use my personal domain jdx.dev, and I've always put my tools there in a subdomain. So it'll be like me.jdx.dev, hk.jdx.dev fnox so on and so forth. So the on dev works well with that, right? You see me's on dev, HK on dev. You know, uh, kind of, kind of makes sense. And then I have a logo that like is inscrutable but it's, it's a Belgian on dive. Uh, like a stylized one on dive and dev. Um, fun.

Speaker B: So I've, the website is beautiful. I see you are creating lots of many uh, nice AI marketing websites. Lots of tools too. Um, so let's, let's, let's keep on the company for a little bit and talk about like the business model. Like what, what are, how are you going to be making money with this? Are you going to be doing like a pure open source thing where you try to just do sponsorships or what's going on?

Speaker A: So um, I'm definitely figuring that out, you know and I'm trying a few things because I really don't know. You know I, I think the most ideal would be sponsorships and also memberships. So I'm doing kind of a, a Patreon thing. Um, I was actually collecting a decent amount of people giving me money on GitHub sponsors before, you know like four or five hundred a month. But that was like without me promoting it and people knowing that like I work at a high pay tech job. You know, I feel like, and this has been true over the last three weeks that like people are giving me much more money now that they know this is like a full time thing. And then, and I'm also doing, giving some perks that I wasn't doing before. Like I got a newsletter, I'm doing like a live stream. So um, so that, that's kind of step one and that's been working out okay. It's definitely not enough to live off of M, but it's like give me a nice cushion and I'm very grateful for it. Um, you know also in talks with companies for sponsorships I think that, you know, there's a lot more money to be made there. It's obviously risky and we'll see. I don't really know until I try to see how much I can make there. Um, but it would be nice if I could just do that because that means I could five days a week, just, just open source. Because that's the goal is maximize open source. Um, but beyond that, like I'm also looking at potentially doing some consulting for companies which would, which would be really great for both me and the product because if I got to go to different companies and integrate me, then I could learn about like where it's falling flat in large companies. Um, so we'll see. I haven't got any takers on that, but uh, and then lastly I'm working on some paid services for me which um, you know, I'm hoping I can like keep that down to not be like a full time job but like building a service and like still optimize open source. Um, but we'll see. You know, I'm three weeks in and definitely not sure which which of these avenues are going to work out best.

Speaker C: Yeah, well, I mean it's good that you have like optionality, you know, you can figure out what feels good and like kind of what you want to spend more time in. So the problem with the business is like, it's very different. You end up having to spend time on things that are not, you know, writing a fun open source project. You gotta, you know, deal with marketing and sales and you know, all the other stuff. But um, you do have a good start. I mean like MIES has like pretty big adoption which I think does make this like a little bit easier to sort of like just get your name out there and like get in contact with companies. Um, so that's ah, that's pretty exciting. I'm excited for you. Uh, it's a hard space I'm sure, but it'll be, it'll be cool to

Speaker A: see what you do.

Speaker C: Um, so you, you have a lot of tools out there and before we like move on to talking about them specifically, um, given that we're on, the notion of your company is like how are you thinking about like the maintenance of all of these open source tools while you're balancing building products or consulting or you know, like whatever else that looks like, it seems like a lot of, lot of balls to juggle there. So how are you going to try to like retain your focus and how are you thinking about prioritizing things?

Speaker A: Yeah, it is Hard right now, you know, the, you know, elephant in the room being just AI PR contributions, which I largely like, but it's a lot. Um, right now I've chosen to let maintenance take priority over everything else. And so every day I sort of clear the decks of like going through my GitHub discussions and PRs that people submitted and get all that done. But really before I move on to anything else, um, largely because that piles up and because it's just me, like, it's got to get done. And, um, in the past, there's been days where I've had to just like commit bankruptcy and just like delete all the notifications and be like, okay, well, I don't want to have to do that. Right? Um, we'll see. I'm sort of this optimist that like, I'll get to a point where like, enough of the bugs are fixed with me's in particular and like, we can move on to other things. Uh, but, uh, yeah, getting the maintenance figured out is definitely a big struggle of mine.

Speaker C: Software engineering is a challenging job and it's harder when you're forced to constantly context which you have email in one tab, Slack in another. Five different Google sheets. So many accounts to keep track of. It can feel like half the job is just dealing with organizational overhead, when really we just want to be writing code. That's where macro comes in. Macro is a tool to cut through the noise. It's a workspace built for engineers. It's one place for all your emails, your tasks, your chat and your documents. The best thing is the source code is available. So if you want to peek under the hood to see how it works, you can definitely do that. If you want to extend it, feel free. The back end is in rust and the front end is in Typescript. It's easy to extend to make anything custom. And the cool thing is macro will pay contributors for any features that they land. So if your team is tired of bloated project management, or maybe you're just like starting fresh and you just want one tool instead of many, give Macro a try. It's fast, it's fun, it's a better way to build. Sign up@macro.com and get $100 off your subscription using DevTools100.

Speaker B: Let's switch to talking about projects because there have been like the amount of projects listed on your on dev website is crazy. And they're all just so high quality and look so useful. Let's start off with OB though. Or did I say it right?

Speaker A: OB ob.

Speaker B: Okay, let's start with ob. Uh, you wrote a Node JS package manager. There's a whole lot of those. Why did you set out to do that and what makes it special?

Speaker A: It was actually my second one. I wrote one about 12 years ago. Um, I never released it. But uh, I really like package managers. It's a uh, big passion of mine. I like reading about them, um, reading the source cod. I've always been to it. I particularly like the node, um, ecosystem. Um, I'm really not a node developer anymore. Everything I do is in Rust. But um, I don't know, something about Node just has always tickled me. I like it for some reason. Um, and I also think everybody's kind of doing things wrong in a few ways there. Um, I think that there's a lot of reasons why I thought the time was right to, to do this, that it would make sense. But the biggest one is just that I thought that there was room for a native compiled node package manager where the assumption is that you're using Node and not a different runtime like Deno and bun. Right. Um, because what I'm saying is like developers, they like Node and I want to stick with Node. Um, and of course like you can use Node and use Deno, use BUN to manage your packages, but it makes some assumptions that that's not the case. Case, right. If you run BUN run, it's going to run under bun, right? Like um, things like that. So you know, I thought there was room for that and I, I thought nobody was working on it. Um, come to find out, Yarn actually was. They have a pacman called CPM which, which they were actively working on. I don't know that much about it, but um. But yeah, like, you know, that's kind of the idea is, is native compiled, so it's fast above all. Um, and then there's like some smaller things like you know, being brand new, I get to make a clean break and fix things that I thought were wrong with the ecosystem. Like for example, every package manager out there has its own um, lock file. And I always thought that was ridiculous. Like should just be compatible. So. Oh, out of the box. It's just compatible with all of them. It's Switzerland. Um, you can use Package Lock, use Yarn Lock, use BUN Lock. It's all good. Um, you know, a lot of the security stuff like the, the post install hooks with Node is like, seems like the number one by far way that vulnerabilities are happening across the industry. So I just took them out, right? And in the rare cases you do need them, OB has a jail, so it can run those in a sandbox. Uh, you know, it's not going to prevent every issue, but it'll get the easy ones, that is the attacks that are happening. Right. Um, and then also there's a thing called the Global Virtual Store, which I didn't come up with. PNPM is already doing it. Um, but it basically lets you put all the dependencies into a directory in your home directory. And then like your Node Modules directory is just a bunch of symlinks, right? So that makes things really fast and it uses very little disk space because it doesn't matter how many times it like prettier 13.0.0 is on your system. It's just referenced in one place. Um, no other package manager has that on by default like OAP does. Um, because doesn't work everywhere. It doesn't work with big ecosystems like Vite and, and uh, Next js for example. Um, but you know, OB knows that and so if you have those projects, it just won't turn it on and then it'll just perform as fast as PNPM or BUN does. Um, but my intention is to push the industry forward so that we can get all these ecosystems onto the gps.

Speaker B: Yeah, a lot of people have tried to do Plug and Play, which is, uh, what you're describing, where it's like the, you have the home directory of things, but when YARN came out with that way back in the day, it was like pain on pain on pain because they did none of those things. Uh, and yeah, it was just a real hard time. So like, did you have to deal with anything with like TypeScript or anything like that? Is there like a, an eject that you have? Like, if I like want to go like edit a node, my node modules to debug things.

Speaker A: Well, uh, so this is set up with, with hard links, so uh, you can go into the directory and it's just, you know, it's, it's as if you were using pnpm. It uses a lot of the same structure. Um, obviously if you start modifying stuff, then that's gonna happen everywhere. But, um, I don't think there's any fixing that. This is how it is. Um, but you know, I think PNPM has really moved the industry forward over the last few years. A lot of people have adopted pmtm and so like, you know, having that, that local model has fixed a lot of the hoisting problems and a lot of things. It's definitely not perfect but um, it's a lot better than it was. And so, yeah, I mean, basically like, what I'm saying is, as long as you're not using one of like five packages, you know, there's big ones. Vite next js. But, um, seems like it's working great, right? I have had very few mention, uh, the GPS not working. It has happened. Um, but like, you know, in all my projects it's been working great. Which is, which is awesome to see.

Speaker C: Uh, I want to just like talk about PMPM for a second because it seems like that's the biggest direct competitor. Now you said, um, for Obey, you're compiling it so it's really fast. Um, and seems to be one of the core sort of features. Uh, PMPM is really trying to push a performance envelope too. That's one of their big things. And I'm curious, beyond some of the other things that you talked about, like lock file compatibility, what was the big thing when you think about PNPM that separates as like, this just isn't enough or it's not going far enough or it's not doing what I think it should do. Are there specific things when you're looking at that that sort of jumped out at.

Speaker A: Yeah, I mean one thing is I think that PNPM is moving in a direction of like trying to be the package manager. You know, like they're re implementing all of the NPM features and stuff. Um, they're really kind of going against compatibility and trying to own the ecosystem themselves. Um, whereas I think that's a big mistake. Right. I think that like maintaining npm, I don't think NPM is ever going to go anywhere. It's always going to be the most popular package manager for Node. This is the alternative if you want to be faster. Um, as a result, it needs to cooperate with npm. Uh, also I just think that, um, one of the things I've done with OB that uh, I need to work on explaining this in the landing page better. But the TLDR is if you're using OB install, you're not using it. Right. You should never run that. Right. Um, OB has a different model than the other package managers where it installs by default. Right. So I come from Rust in Cargo. That's just how things work. You run Cargo run, it's going to compile stuff if it needs to compile and it does it so fast that like doesn't matter. Right. Um, the equivalent of that with NPM would be NPM Install and, and NPM Run Test. It's too slow. Nobody wants to do it. PNPM has a native command for this PNPM install test, but it's still really slow. Uh, with ob, I have a hidden state file that I use with a bunch of checksums that can super quickly validate if it needs to install. Um, that's how I can get it sub 10 milliseconds. If you do OB run test, then um, by default it's going to run install if it needs to happen. Because working in dev infra for a long time, seeing developers work with node, the most common thing for the last two decades almost has been uh, forgetting to run NPM install after pulling down a branch. Uh, even agents don't do it. Right. Uh, and this is ridiculous. I'm sorry, this should have been fixed years ago, but I'm fixing it now, um, with just like having that behavior. So, yeah, nice.

Speaker B: So there's a lot of features that like I've come to rely on in a package manager. Probably the biggest one being workspaces. Does uh, OBS support workspaces and kind of like those more nitty gritty detailed features. Like another one I use a lot is overrides like when I have to like force a certain version of a dependency to make the types work.

Speaker A: Yeah, it does. Uh, I am uh, test cases and going through them one by one to make sure that every little tiny little feature there is used. Um, but I'm at a point now where I'm fixing bugs that nobody's running into yet. Uh, and I have no idea how popular these features are. I think very, very unpopular. Um, but I want OB to be a drop in for pnpm. Right where you uh, can just, if you were using PNPM before using any packaging should work but like specifically pnpm, um, because I think that's the most direct competitor. Right. That's the alternative, but faster. OB is the same thing, but it's a little bit faster than pnpm. Right. Um, and so yeah, like I've done a lot of work around that. Pure dependencies in fact were way harder than I thought they would be. But I think I finally got there. Yeah. Yeah.

Speaker C: Cool. Maybe one more question before we move on and talk about some of your other tools that you've made since we last talked. Uh, I want to hear a little bit more, more about this gel. Um, so supply chain attacks, uh, happening what seems like every day now, like in massive packages with many, many, many installations and it's increasingly scary. So how are you approaching security and like what does that isolation of like post install scripts and stuff look like?

Speaker A: I mean it really across all the tools I'm making. This is, this is a big deal. Uh, you know, me says some new sandboxing stuff too. Some of the service I'm working on for me is, are having remote jails so that, so that I can build your tools for you in a jail. Um, and like us with ob, you know, I'm not planning any services for me or sorry, with ob I'm not kind of monetizing that. But like I do want to at least have jails so that you can run those hooks securely. This is not on by default yet, but I pushing hard to try to get that done. I'll probably do a breaking change v2 like sometime in the next three months. I think once I get a few of these things stacked up of like, all right, let's make this default behavior. Uh, one of them I think will be the jail. Uh, and so what that does is in on macOS it uses seat belt. On Linux it uses landlock. Uh, and it locks down the network, it locks down the, you know, the drive so that it can only access certain things. Um, and so you know, the most naive attacks which are the most common of like look around for EMV files across your hard drive are not going to work. Um, so yeah, that's the idea. But again like the lifecycle are off by default. So you have to like one by one say I want this to use lifecycle hooks even with a jail. Uh, and then the behavior will be like okay, I've turned on this package. The default is going to be still running in a jail. So it'll be like three steps to get a package to run a post install hook without a jail. Which I think is the way it should be. Dependency should just not have them. But uh, it's a reality for right now.

Speaker C: Yeah, especially native dependencies though, which is a thing that NPM ecosystem is actually used a lot for is just like to, you know, I have a Rust project and I'm also like, you know, distributing it on NPM and you have to like pick which is the right binary or whatever. Uh, tends to be a thing that you see used.

Speaker A: Yeah, I think that might get better with Node 26 because they have new FFI stuff. So I think I'm not too familiar with it yet but I think that might mean uh, we don't need to do some of that.

Speaker B: That'd be nice because it is definitely one of the most annoying parts of the Ecosystem, especially like when having to deal with CI stuff. Cool. Let's move on to another low level annoying type project that seems like you like to tackle, uh, hk. So HK is your take on git hooks. Can you tell us how it's different than like the incumbents?

Speaker A: Yeah, I mean this is easy. HK is completely different. Um, you know, so, so I think like githook managers have a few different forms. You've got things like Husky that are really just like making it so that you can run a uh, bash command when pre commit runs. I think nobody should use those anymore because as of like the new version of git that just came out a couple of weeks ago, you can have global hooks, uh, which means you don't need to do that thing where you need to like add a git slash hook pre commit. That's like really a lot of what these tools did. You just have it in a global and it'll just work in every project and that's what you should do. Right. So yeah, there's that category which I think is dead now, uh, or on the way out. And then there's the category of sort of pre commits and pre commit the tool and prec and another one's just gave me and that, that's, that's you're kind of getting to like where they run linters too, right? Uh, where you like in pre commit you have plugins that even know how to like install tools and stuff. Uh, and know how to like run prettier or rough or whatever it might be. Um, and then HK is really a level beyond that where like so like with, with pre commit it's uh, it can only really safely run things in, in series, right? Because like it's running things that edit the files before a commit is made. Um, and it's not generally safe to run in parallel. Let's say eslint and prettier at the same time in the same files for obvious reasons, they'll stomp on each other. But in HK it is safe. And the reason it's safe is because HK has like deep integration with these linters. And so if it runs rough, for example, it'll run it with dash dash diff. And so it doesn't have ruff make the changes on disk, it just asks rough what the changes are that need to be made. And HK itself makes those changes. And so that, that's what lets it be faster in practice than any other tool because it can, it can run all the linters in parallel safely. Um, and then also like it, it has a bunch of built ins. So like the downside of that is you have to configure it for each one and know how to configure it correctly. But I've done away with that because it just has at least 100 built in linters. So the ones that you would want to use are, are already in there. Somebody's already figured out how to, how to make it work.

Speaker C: That's awesome. So it's trying to like, for a lot of the like formatting tools, it's like you have, you know, eslint that's doing some formatting and prettier that's doing some formatting and you're trying to um, figure out like what the outputs would be and like composing those together. What if there would be conflicts between the two tools that you're running? Um, it just runs it again. Just runs it again.

Speaker A: Uh, yeah. So, and it'll, it'll run a subset, right? So if that happens it's going to be on like one file, right. And so they can run a subset. This doesn't work with every linter, so sort of different levels of, of integration. Not every linter has a dash dash div. Some of them can only work by editing the files directly. And so HK does a bunch of stuff. So one of the things it'll do is if, if the linter offers the ability to tell you which files have issues, which let's say prettier does. Prettier does not have disk dis, but it does, it will tell you which files have issues. So there's a whole like read write lock thing. So first thing HK does is it gets a catalog of here's all the files in the repo and it has read write locks. And so it'll get a read lock on say all the JavaScript files, run prettier and say which files have issues. We get that list back and say these two and it gets a write lock. So that's an exclusive lock on those two files and it runs the fixer on it. Right. And so that's, you know, that's kind of how it works. And you know, in some tools they need write access on all of them. It's the only way they work. And so with those there's no choice. It just has to get an exclusive lock on all those files.

Speaker C: That's really interesting. Um, it's cool. One of the other sort of like design decisions that I wanted to ask you about, um, so it's a little bit of divergent from the previous topic but uh, so HK is like configured with this uh, script, uh, this configuration language called pkl Pickle maybe, I don't know, uh, not to be confused with like Pickling, uh, and Python. Um, so can you uh, tell us a little bit about PKL and like why you chose that? I think this is the only project that I've seen use this configuration language and it was like kind of fun to stumble across. So curious about that.

Speaker A: Yeah, it comes from Apple which is fascinating. Right? Like I can't think of another open source project aside from maybe some of the BSD stuff they do. Um, yeah, so, so Apple. I don't know what Apple uses it for, I don't know if it's anything public but um, it is sort of in vein of maybe, let's see Nickel and a few of these other sort of like compile to YAML languages might be fair to say compile the TOML compiled to JSON. Um, and it lets you just do templating basically I think is the way to think about it. And it's safe. So if you import a um, Pickle file then it can't run commands and execute things. If you import a Python file for example, it'd be very dangerous. But Pickle, it's. What's the word I'm looking pure. Right. Um, and so ultimately HK gets this JSON representation of the pickle. Now the reason I'm using it is because um, you know the, the built ins I was talking about, that's all written in Pickle and so that it basically has made it. So I don't need to have a plugin interface because the configuration is comprehensive enough and powerful enough. With Pickle there's no need for it. Uh, you just, you can, you can create really complicated things right? So like you could have something where uh, you know, you, you can have your own rules about like I want to run just these hooks if this environment variable is set. You know it's like really powerful things. There's no way YAML could do or any other simple configuration language. So yeah, I mean it's um, something new for a lot of people. I think it's hurt the adoption frankly. Uh, I don't know if I would recommend people choosing it but it was such a solid fit for hk. Uh, I'm glad I, I chose it. Yeah. And it's fun, you know,

Speaker C: fun name for sure. I think. Uh, yeah, I don't know. Configuration, Configuration languages in general kind of stink because like JSON's not great YAML's not great. Like, JSON 5 has been the one that I've been using most lately. And it's like, you know, it's better I can comment things and don't have to quote everything. That's nice. But yeah, uh, the. The sort of like, composability of this, like, is really nice because I saw like, in the docs, it's like, oh, just like import, like this extra, like, configuration here and it's like. That's pretty cool.

Speaker A: Yeah, you write your own functions and stuff. It's. You can do. It's extremely powerful. Yeah.

Speaker C: Cool. Um, I think we'd be remiss if we didn't talk about, um, how this intersects with Mises. Uh, so it's like Mises sort of. You're like, you know, central project, and a lot of the tools that you build in some way, like, have integration. So, like, what is the. What is the HK like me's story? Like,

Speaker A: um, there's really very little. And that's intentional. So, like, uh, there is like, mise integration in hk, but like, it does such. All it does is it prefixes stuff with misexecute misex. Um, so that like, all the tools are loaded by mise.

Speaker B: Um,

Speaker A: I could have gone a route where you could have a tools field in the HK pickle config where you could say, like, I want this version of Node. Run this thing. I haven't done that because it's not necessary. Right. Like, the thing that like, mises really well is it's really easy to do that with any. Anytime you've got bash, which is what's in your pickle file, then you just do mees X node at 20. And then now all your prettier stuff's running under node 20. Right. Um, and so like, you know, things integrate, but just by virtue of like, because Mises already really good at doing that with any kind of shell script, you know. Um, the other place that is like, you know, there's not. There's nothing built into MIES around this. But like, all of my projects have a mise run lint and MI run lint fix. And then they also have like a M run CI, which is what runs in CI, and then that has a dependency on lint. Uh, and then that lint is going to run hk. Um, and a lot of people are doing that with hk. In fact, I'd probably guess most HK users are MISE users. Um, and they probably have a task that does exactly what I'm saying. And there's nothing in me that describes that. It's just like, that's just the natural way that you would do it. Uh, you know, and so I think, like, I don't know, like, we've got the fundamentals figured out over years of working on this. And like, these things just sort of interoperate together. Because it's built on unix, I think it's kind of the long and short of it.

Speaker B: Okay, let's move on to something the docs literally, uh, call out, this could have been in me, but isn't. Uh, Knox, uh, Knox is your secret manager. Can you tell us how this one's different and why it wasn't in me?

Speaker A: Yeah, so secrets are something that people wanted from Mise for a long time. Secrets are a really hard problem. Uh, and so part of the problem is Mises runs all the time. So if you run MEES X, if you enter a directory and have Mise activated, MIES has to sort of refresh all of its environment variables. Um, and if that's just node and equals development inside of music toml, that's cheap, it's no problem, right? What people wanted was 1Password, right? They wanted to have, you know, I want my environmentals loaded from a secret and 1Password or Amazon Secret Storage or any kind of remote provider. And I never implemented that because it'd be incredibly slow and you can't cache it, right? Because these are secrets. Like, uh, you don't want to put them in a plain text file on disk somewhere, even encrypted, because in that key I need to have a way of decrypting it, right? So it's very dangerous for me to do that. And so that's what was never done by virtue of like, being a separate tool. And FNOX just doesn't have to run as frequently, right? So like every time you run mizrun, it's got to load that environment. Um, but because FNOX would have run separately, when you enter the directory or run FNOX Exact, then it's only running really when you tell it to, and so it's cheaper. Um, the other thing I really admired was a tool called sops. Um, so SOPS is sort of encrypted JSON and what is commonly used for is to have encrypted environment variables of secrets in your repo and then use something like Augate to decrypt it. Um, and so I, I really like that pattern. Um, I've seen it used a lot of companies. It works really well. And so I wanted to integrate those two worlds. Because you know the pattern that I'm seeing that I really wanted was like I want to have secrets and let's say one password and I want to encrypt them with a KMS token from my company's AWS account. Um, and store those on disk and not committed. Let's just leave it like a developer's machine. Um, and then that, that sort of gives you like a nice balance of being fast and secure, uh, kind of all at the same time.

Speaker C: Yeah, I, I really appreciate this project a lot because like I uh, didn't, I didn't realize it's called auge. I thought it was H. But yeah, the, the. So I've tried to use uh, SOPs and AGIA before like and like together. But like the DX is a little tricky especially if you're collaborating with people. If it's like just you like. Because every person has to like create the secret key, you know that you have somewhere on disk. Um, potentially. Uh, and you have to uh, you know, re encrypt the file basically with your, your signature in there. Um, and then like adding new team members is this weird song and dance where you know, it's like do you, you pass your, your key to me? Or like how do I, you know, you give me your public key and I'll list it and re. Encrypt it or whatever. I don't know, it just felt strange and I do enjoy how that experience is like improved. It feels like you, you did elevate the, the DX of that and also just like being able to then like integrate something like 1Password or whatever just into that same flow is nice because like you know, I can get the secret from 1Password to do the thing and like it's um, yeah it's pretty nice. Um, is there any like other features of, of Knox that you feel like is like kind of under socialize like something that you're really proud of that like people might not discover.

Speaker A: Like uh. So there's, there's stuff with um, leases and I, I, I, I wouldn't say I've nailed the DX here but I like the direction. Uh, actually a lot. Like FNOX DX wise I think is a little unfinished for me. Like I, I like what it is. It, it's got room to improve. Uh, whereas like with hk, I think HK is very mature. I think I've, the DX is quite good there I think with fnox. So Elise is uh, short term credentials. So the dream I have is, especially with the Gentic programming is some way that an agent can say give me a cloud failure token that's good for an hour and maybe I can get a prompt on my phone to even approve that. And there's no way the agent can get to access to the long term credentials somehow. Um, I don't quite have this. Leases are like part of the way there. So with Elise you can do something like store um, something encrypted that can get decrypted with the Yubikey for example. So you have your long term token has to have a Yubikey press and then that can give you a short term token that then doesn't need that. Right. So you can do stuff like that. Um, but I'm at the mercy of the providers in some ways. Especially GitHub is like not very good support for things like this. Um, you know, but like that's kind of the thing I want to solve is, is getting rid of long term tokens for development, you know. Um, but we'll see. Watch the space for sure.

Speaker C: Yeah, that'll be cool. I was actually curious about that. I hadn't used Lisa's yet but

Speaker B: um, so before we move on to talking a little bit more about me, I want to ask you about your AI usage because like you have so many projects and they are very high quality. I'm not saying they're slop at all. Uh, but to like do this much work you must be using AI in some way. So like what does your flow look like? How involved are you with like each project? Like do you kind of like just shoot stuff off and kind of like come and look back? Or is it more of like a one on one experience? I'm interested to hear.

Speaker A: I, I really like AI. I um, I get a lot of use out of it. Um, I, I've recently switched to using the desktop apps from the tys. So I've, I've been using Codecs desktop and, and Clogged desktop. I really like them. Um, and, and I also make heavy use of like Greptile on my projects. Uh, AI code review is, is, is super handy. Um, and, and I also like something that like people ask me about a lot. Is, is. So when I reply to people having issues I, I pretty much always do it through Claude. Uh, and I put a little like disclaimer on there just to let people know that it came from Claude because like you never know. Right. But I do read it and you know, so this isn't, I think people think that this is a bot that's replying to them, especially if it happens quickly. But no, this is coming from me. I. I prompted Claude. I read what he'd said and I said, yeah, go, go say that to the user. Um, because it just has all this information in there that would take me an hour to write. Uh, which is very useful context for the user. Um, even though it might come across as mechanic. And I know people would love a human response, but I just don't have the time for that. Um, I get 1,000 GitHub notifications a week, so this is really helpful for me and it allows me to respond to people because before I just couldn't. Um, but, yeah, and then I think with projects, like, I'm, I'm, you know, like, I don't use skills or anything. I have like a cloud MD in my repo. Um, but I think with open source, the context just isn't that big as it is if you have like a large company with a big monorepo. Um, so tools work really well. And I think also, like, because I make CLI tools, mostly AI is quite good at them, you know, Like, I, I'm sure we've all heard, like, maintainers complaining about slopes. Um, the quality PRs I get are actually quite good. Uh, I do get slot, but it's very rare. Like once every couple of weeks maybe I get a PR that I'm like, this is crap. But like, most of the time it's good quality. Um, and you know, it still takes my time to review and everything. But, um, I think a lot of that is just that I write clis and those are just kind of easier for agents, it's my guess.

Speaker B: Yeah, the, the UNIX manifesto of do one thing and one thing well probably lends itself well to like an AI going, oh, well, what fits here? And like, what makes sense?

Speaker A: Yeah,

Speaker C: it's probably a lot to be said about using the tools a lot for your own development too. And it, like, propagating the patterns that they're already sort of like, good at. Um, I don't know, something interesting there. Cool. Should we move on and talk about mies? It's been a minute, uh, since we discussed it, uh, and we've mentioned it a lot in this episode. Not really, like, talked about it in depth. So maybe if you've listened this far and you don't know what it is, maybe we'll give you a refresher on what it is and then, uh, yeah, I would love to hear, uh, some of like, what are the latest things you've shipped and.

Speaker A: Yeah, yeah, so Mesa is quite mature. It's been around for almost four years now. And um, the quick version of it is it's uh, development tool, manager environment, uh, manager, sort of like Durham. Uh, and it also does tasks sort of like make or just, or task file or things like that, but kind of all in one. Uh, the tagline that I've kind of moved away from, but I always really liked is the front end to your devm sort of. The idea is, I would think that like, if, if you're, if you're using it to its full extent, then like Mises kind of the only thing you're talking to. Um, you know, but that said, I'm nervous to say it that way because I think the thing that MIES does well, that this is very intentional is it's not a system in a way that Nix or Buck 2 or Basil is. It's an overlay is a better way to think of it. So like you can, you can adopt me and just use it to like run one task or install one tool or set one environment variable. It works great at that. You can use it on top of Bazel. It works great. You don't need to go all in with it, you know. And generally what people find is like, they'll say, oh, it works great for this and then they'll use it for another use case. Another use case. But like, nowhere along that way is it saying like, you gotta use me for everything. Um, so yeah, that's held true today. Oh, to answer your question about like, what's come recently, I think the two biggest things I can think of is one, experimental monorepo support. Monorepo support. It's still an experimental, um, but this solved a problem of like, I want to run NPM run tests in a monorepo against a bunch of sub projects where each of those projects might use a different version of Node. Um, so you can do that now with this experimental support. Uh, the lock file was, was a huge challenge, still a little bit hard, but that has come out of experimental and is working pretty well, I would say. Um, it's hard for me because Mises is not just one ecosystem, right? Like if you write a, uh, lock file for Node like opas, it just has one shape of dependency to worry about. But mises compatible with pip, with GitHub releases, with SPM, with. And people can bring their own, right? So somebody wrote a, ah, Nix plugin for me and so now it can do that. And so like all this stuff needs to integrate with the same log file. Um, and that was really hard. It took me almost two years to get that out of experimentl but it's finally here now and uh, that helps a lot with um. I think two of the biggest problems that Mises always face and will always face. One is the GitHub token, which is uh, you know, mises a lot of talking to the GitHub API. And uh, GitHub has very strict rate limits of 60 requests per hour. So basically it's unusable if you're not authenticated and getting that authenticated. It's not Mises fault but like if you're using it, it's the fact that M. That's where most tools are. Um, and then the supply chain security stuff, you know, I've, I've tried to adopt everything I can from Sig Store to Cosine to um, those are the same thing. But uh, GitHub provenance basically if a vendor offers a security feature I want MIES to adopt it. And so from the user's perspective they can just trust that me is going to use the most secure way of making sure that the bits that it's getting are what they claim to be. Um, and the lock file helps that because it can define what those rules are for that particular tool.

Speaker C: That's cool. Yeah, it's a hard, seems like a really hard problem. Um, just, just that like managing multiple tool versions. Uh, I will say I don't think I've run into the GitHub, uh, API rate limit very often. So I think you've done something there. Uh, I think I've hit it like once. But um, yeah, that's, that's a really tricky one. Is that something that you've been thinking about of like how do I, you know, like, especially with like GitHub's like instability that becomes like, you know, whether or not it's your fault, it like seems like, oh, this tool is like failing all the time because of like not being able to install things and it's like GitHub's like down again.

Speaker A: Yeah, well actually uh, this is an opportunity for me. Right. So that's one of the services that I want to make is a proxy in front of that so that, so that you can have some security that the stuff you're getting isn't going to rely on GitHub. Um, uh, but um, yeah, I'd say there's a website called me's versions.jdx.deva and if you go there you can actually go to the stats page and look at where things are coming from. And it's like 95%, I think, are coming from GitHub. Um, and so, yeah, I mean, that's where vendors are putting their stuff. And so it has to work. Right? You know, there's Also, like, with GitHub, there's, you have the API and then you have the tarballs, and they're really like, on completely different systems. The tarballs actually usually work all the time. It's very rare for that to go down. The API goes down all the time. And so this is where the lock file comes into play because the lock file puts the URL of the tarball so it doesn't have to resolve that, um, when, when things go. So, you know, my advice is, if you're using me, you should, you should use log file because it, it just bypasses a lot of the GitHub problems. Maybe it's not obvious that that would happen, but that's how it works.

Speaker C: Cool.

Speaker B: Uh, so is there anything else that's like, left for you to build with me? It seems like you're kind of in maintenance mode and like, just like shaking out all the bugs before you move on.

Speaker A: Mostly there. There's a story around dependencies, you know, so, so Mies does, you know, the dev tools, environments, tasks. I've always wondered if it could do dependencies too, you know, so, like, this is very cool, but I don't know how useful it is. Uh, like me could be this like, polyglot package manager. So you could have like an NPM package to depend on the pypy package. Now I don't know why you'd want that, but I could build it. Um, yeah, I am playing with dependencies because going back to Ober, I was talking about the cargo model of like cargo run just does the installs of everything. This is not just a node problem, it's problem across everything. And where me is really abstracts away the tool, installs, runtime, installs. Um, I think it could abstract away the dependency install too, so that you could have that same experience no matter what language you're using. And so there's a new experimental part of the code base. It was called Muse Prepare. I've renamed it to M Depths to really focus on dependencies here. Um, that sort of does that where it can, you know, run bundle, install if it needs to run before running Ruby code, for example. Um, definitely still playing with that. I don't. I'm like, probably 40% sure that I will like take that further than it is. We'll see. But that's, that's probably the biggest rock that, that I might embark on. And also secrets. I could see that maybe, maybe we do bring that back from F Knox. F Knox is kind of a test bed of me trying out ideas that I'm not quite ready to get into me's, uh, around Secrets because again, I haven't figured out the DX there. Um, and I think it's very possible if I did get F. KNOX to a state where I really liked it, then that maybe could come back into me. We'll see.

Speaker C: Yeah. I think having FNOX be separate is not necessarily bad just because it does, um, you can have like a different security posture and you know, there's, there's like some opportunities there. Uh, and it also has a, you know, pretty broad surface area already. I think like me's getting larger is, you know, uh, it'd be one of the things to sort of like balance is like, how much extra functionality to add. I will say the dependency thing is really interesting because like, so pretty much every me's project that I set up, the first thing I do is add like a post install hook. And that post install hook will run the package manager installs for like, whatever things that I'm using. So if it's a, you know, a node project, it'll be like PNPM install and the post install hook and that'll be like the first thing that I do. Recently been using it in a monorepo setting and that's been interesting. You like really some like, cool features for monorepos, but monorepos are weird because you may have like a tool version that's like at the root, um, but you're like running something for a dependency and like misel, at least make sure that the tools are installed. But like, I can't use like a post install hook there to. I don't know. So that's like one of the areas where I'm like, I want some way to say like, hey, check that the dependencies are installed. Like, you know, or like a thing to say that is like, you know, because it's like you. At the end of the day, if you were trying to implement this for like all the package managers, something you'd have to figure out like, how do they all do checks and stuff. But like, if I had a way to say like, oh yeah, this kind of depends on this thing. Make sure, um, that you know this, these packages are installed. Uh, and lately I've been trying to use like a setup task, um, and like, add that as a dependency to all the tasks and like, use the. You have this like, cool feature to like, check if like, something has changed. Like, um. And that's been relatively helpful. It's just like, kind of verbose. And, um, so it's like, I'm still trying to figure. Figure that one out, but maybe something there.

Speaker A: Yeah, yeah, it's. It's not a solved problem with me yet. Yeah. Um, but yeah, that's definitely an area I would like to tackle for sure.

Speaker B: Justin, want to do the future question?

Speaker C: Um, sure. Yeah, Sounds good. Um, cool. So as we're wrapping up here, um, and sort of like reflecting on the things that you've built recently and thinking about the things that you've built in the past and you're, you know, exploring this new company, which is, which is so exciting. Um, what are you, like, what are you thinking about next? Like, what's like, up, you know, on top of your agenda? I know you're, uh, like working actively on O, so that's new and that's like, uh, an active development. You're still doing maintenance in a lot of the projects, but, like, what's the next thing for you?

Speaker A: The services? For me, for sure. Yeah. Um, and so like, the. This is still up in the air. This is a spike. But like, right now it's sort of a cross between something like Artifactory or Nexus, but also like Docker hardened images. So I found this, actually a user pointed me this really cool thing in OCI called OCI Distribution Spec. Uh, and it's, it's a way that you can use OCI to make things that are not containers. And in my case, I want to make tools that I'm using OCI as a distribution method. The reason I'm doing that is because OCI has all these really great, uh, security features and Provenance checks, S BOMs and like, all this stuff is very standardized in the Docker container world. And so like, I'm, I'm taking advantage of that to. To basically, um, build tools inside of these OCI containers that it's really for companies that want to have like a policy where they say, like, I want only tools that are this new that passes all the provenance checks. We need SBoMS because if a CVE comes out, we want to know like, which computers were infected with that cve. Um, and so it's quite exciting. Um, that's like the biggest focus I have. Uh, the other thing there is also like uh, OCI is so heavily used that you can put ECR or Artifactory or anything that can talk OCI as a proxy between me and that. And now all your tools are cached and very fast, uh, with sort of, like, commodity stuff that just needs to know how to talk oci, which is so many things now. Thanks for having me again. Really like it.

Speaker C: Yeah, thanks, Jeff. Um, Miza's amazing. I use it every day. Um, so I appreciate your work on it, and I wish you the best of luck on your new endeavor. Um, it's really exciting to have someone else try trying to make open source sustainable and, yeah, hope for your success.

Speaker A: Thanks so much, guys.