Next-Gen JavaScript Package Management with Ruy Adorno and Darcy Clarke

22:58Ruy Adorno:So there is also that component that I lay the big part on why the law exists. So it really serves multiple purposes like that. And at the end of the day, it is also serving the humans that are managing these projects because they can keep track on how the dependencies are evolving, right? And it's something you can audit after or during each install in order to make sure you're really getting the artifacts you're supposedly getting at the end, right? So it has multiple purposes and it is a fine balancing act trying to serve all these different personas Well, there's a difference in use of log file in a way that it works great for not everyone, but it's a step of the way, right?

23:51Ruy Adorno:Yeah. I'm going to give you what sounds like a softball question, but I suspect it's not. Let's say that I package A that requires B at 1.1 or higher, and then package C that requires B at 1.1.1 or higher. Why is it so difficult just to figure out what versions of packages A, B, and C I want? Or why is dependency resolution with versioning so difficult in the package space?

24:16Darcy Clarke:So in general, I believe you just used some grammar, right? Like some non-standard Semver grammar. Is that right?

24:24Ruy Adorno:Yeah, I gave you an imprecise Semver resolution specifiers for these packages.

24:29Darcy Clarke:So this is something that a lot of folks take for granted in our ecosystem. And in fact, they take it quite for granted in most packaging ecosystems. There is no actual specification. There's like a quasi specification or standard for ranges or essentially like groups to be associated together of software versions. So every time we say Semfer, we're kind of actually we're stealing a term that actually doesn't have any basis for the ranges. Like ranges have not been codified in the Semverse spec, just so everybody knows. If you want to go check out the Semverse spec, you're going to find that it only codifies what a version is.

25:10Darcy Clarke:It doesn't codify ranges. It doesn't codify to group things together. Like how you do that is all based around how the package manager interprets that spec. But definitely in terms of how do we group, let's say, A and B or two versions of C when you get into what we call the diamond dependency problem, where you have two different disparate dependencies that both have a transit of what we would call a transitive dependency. And you have them at two different explicit versions. In some ecosystems, let's take Java, you can only ever have one version of a library. So you have to get rid of that conflict.

25:50Darcy Clarke:What we would say is a conflict between those packages that are these dependencies that have different transitive dependencies. And you have to choose one, right? You have to basically say, oh, I'm going to choose one. I'll take maybe the greater one. The beautiful thing about the JavaScript ecosystem is many years ago, Isaac Schluter, who created NPM, and he was a benevolent BDFL for a while taking care of Node, was able to figure out that, hey, we can actually get around this problem by allowing multiple versions of the same thing to exist in a project by nesting these dependencies, these architectures.

26:25Darcy Clarke:And that's a beautiful way to kind of like resolve that problem. And I would say that's, I like to call that like the first layer dependency hell, where you have this issue of I have these two direct dependencies that then have a shared transit of dependency that we associate being the same thing, but need to resolve to only of one thing. And the way that you can do that if they are truly in conflict is to just have two of them, have two versions of those things. And we would say that's like the nested strategy for a package manager will opt for what's the easiest thing to do is like, we just don't ever try to share these two versions.

27:05Darcy Clarke:Like you don't ever try to do what we call is like deduplication of your dependency graph. But when you do want to do deduplication, because there's many reasons you want to do that. You have to then come up with a grammar, which is like that non-standard grammar that we have for greedily or having sort of some slipperiness between your dependencies that allows you to opt into versions that may not exist today, but could exist in the future that allow for us to optimize for getting the best, most evergreen version we can without breaking software along the way. So that small little example, I think really, and I'm not sure if I'm doing a great job at summarizing this, but it really, I think, unlocks many of the details and nuances of what it means to do package resolution and also the problem of dependency hell in general that we were facing back in the 2010s.

28:01Ruy Adorno:Really sounds like it puts the hell in dependency hell. Yeah. Resolve multiple versions of packages with different strategies per package manager.

28:09Darcy Clarke:It's one of those things that we all have to understand that there's this language the package managers have in their brains, this sort of parsing that happens of the specs that we put in our package JSON files. And these dependency specs, a lot of folks take for granted. They sort of are like, that's just a sender value. Well, actually, no, it's not. That's going to do something different potentially. And we spend a lot of time talking about grammar and definitions and specs and schemas in the package manager world. And I would say like one of the things that I constantly ask other people is like, what do you think a package is?

28:50Darcy Clarke:Like, what is a package? And I get many different answers to that. Or what is the most minimal thing that could represent a package? Like, what does that string look like? and I gave many different answers to that. All right.

29:05Ruy Adorno:We've talked about the base of what a package manager is, what a registry is. I want to focus a little more on Volt and what's coming up next for y 'all for the next bit of the interview. You've re-implemented the core parts of the manager and your registry and you've added in some niceties like working on the edge and you duplicating for better performance. What are the other selling features or parts of your product that you're excited about?

29:26Darcy Clarke:So we are starting to roll out net new features to the client and the registry. One is obviously being safe by default has become standard. And what I mean by that is not running arbitrary scripts or install scripts has now become cool, which I'm very happy about. Our package manager obviously takes care of this by default. If you run vault install, we're not going to run any install scripts. And we're going to print a nice message, which we just shipped recently. Roy was actually the one to implement this feature. and we utilize our amazing query language, which is the other sort of core feature of the client, as well as we're putting this into the registry to allow you to do sort of a nuanced allow list if you do want to opt into running those install scripts.

30:17Darcy Clarke:And you do want to create some kind of configured, codified list of dependencies that should be running in, let's say, install scripts, because there are legitimate reasons for that. Mounting native binaries, free runtimes, or just generally building a package that you think is secure or you trust it because you've seen it before. And so that's a huge unlock. We call that, we've created a net new command in the Vult client called build, which takes one of our query selectors, which we think is super powerful compared to sort of what the other package managers have done, which is just used package names and package versions.

30:54Darcy Clarke:The query language itself is like a huge unlock in terms of being able to expressively write both with relationships or with metadata, something that selects within your dependency graph, very nuanced, noteless, essentially. This language is very much inspired by CSS, which I have a soft spot in my heart for. Not everybody does, especially the Tailwind folks out there. But it's honestly, I think, the coolest thing that we have. And we are seeing the benefits of using it in our core graph logic by unlocking something like this, which was super easy for us to implement. And we're super happy that we can say as well, along with PNPM now and Bun, that we're safe by default.

31:41Darcy Clarke:We're not running install scripts. So that's a recent unlock. Another recent ship that we had was just the ability to actually select in that query selector syntax projects across your whole system. So Roy also shipped this. It's called the host selector. You can literally write a selector that will query for any project that's being configured or installed with fault. And we can essentially do cross project. So if traditionally you're using monorepos, you'll know that it's totally easy to obviously select projects or list dependencies in your monorepo projects. But actually sharing dependencies, configuration, or doing querying across, let's say, many monorepos or many repos hasn't been possible before.

32:29Darcy Clarke:So the selector essentially runs in the global context of your system and can essentially go and query anything that you can query for across all the projects we can find on your system that are configured to the Vault client. And Roy, I'm not sure if you want to dive into more on that, but yeah, that's the high level of what the host selector does.

32:53Ruy Adorno:There's so many directions we could go from here. We could dive a little bit more maybe on the query language itself, what it is, how it works. Or maybe the other, I think another pillar of that is having a browser-based UI. And I think that's also fundamental for a lot of folks out there to actually be able to visualize. Like when you're applying a query, what packages are you actually selecting? because then you have a real-time experience that allows, you know, to traverse and navigate your install using the query selector in a more user-friendly way. What's an example use case of this that hasn't been brought up yet?

33:31Ruy Adorno:Like, let's say I'm managing a monorepo. What are some things I might use this query selector syntax for?

33:36Darcy Clarke:So a lot of the time it's useful for auditing our observability, but also it's great for transposing configuration or setting setting and getting values from different package json's, let's say. We actually introduced the PKG command into NPM when we were there. We've obviously carried it through to the Vault client, which we think is great. Bun itself just introduced it in a recently minor version. They now have PKG as well. It's kind of like the fun JQ built right into your package manager. And so the great thing here is you can get and set and remove or unset values in your package json. a file.

34:17Darcy Clarke:And utilizing query selector syntax, you can imagine you can start to share configs, you can share dependency definitions, you can share all types of things and actually get and set those across your projects very easily. So you can sort of transpose and automate, you know, the config definitions that live within package JSON across your monorepo. So there's a lot of automations that this sort of unlocks. There's a lot of, you know, things that we think even we haven't conceptualized yet. But the idea here is you can quickly go from having sort of like a template for your workspaces that may have, you know, a whole bunch of test scripts that you define and you can go and then action a set, you know, a package set utilizing the query selector syntax that go and pick up that definition and then apply it across all the workspaces.

35:09Darcy Clarke:So we look at it as like being very composable, right? So the PKG is a great example of what we think is a great, you know, composable subcommand within the client. And with the powerful query selector, which we've added to almost all, I think all of our commands now support essentially a flag called the scope. And the scope is essentially just a flag for defining the query selector that you'd like to apply that to. So you can even do publish, pack and publish. We have those traditional subcommands for creating and distributing packages. We also have install, obviously. We have version, all those commands.

35:45Darcy Clarke:They have this special flag called scope, which you can define as a query selector. And it means that that operation will be ran against that selector, like those dependencies that match that selector. So it's kind of like PMPM, if you look PMPM and their filtering syntax, it's kind of like the filtering syntax on steroids, which I know I really loved what I saw when Sultan brought out that filter syntax. It's just a little bit bespoke or Baroque maybe. I don't know that term, but you know, it's a little bit foreign for I think a lot of developers to know what specific, you know, little dots or slashes you have to put.

36:24Darcy Clarke:I really don't want to have to remember like, you know, XPath type selectors. Like CSS to me was just the perfect kind of, you know, in between between something that's super expressive, but also super powerful. And it only gets better with the more metadata that you put into your packages and your fancies. And we can select by that and we can select by other kinds of states for your packages. So yeah, huge unlock for, I think, workspace management is the selector syntax. And then we're trying to create more and more of those primitive kinds of operations like PKG or run or even exec all support this.

37:01Ruy Adorno:So, yeah, expanding a little on your example, just to give a concrete example here that I find is pretty fun. Let's say you're SYNG, right? And you have over a thousand packages out there, right? Let's say you configure all of them using Code Client, right? So now you could go ahead. Let's say you're just migrated. You moved from Twitter and you're now Blue Sky and you want to update all your package JSON to update that metadata everywhere. But let's say you have some other conditions you want to apply. Maybe you just want to apply to the package where you're actually mentioning open collective for some reason.

37:41Ruy Adorno:So this language just gives you a very powerful way to express all that. But you could use a command like vote pkg and go ahead and set your social media handler to now point to Blue Sky instead. And you could be pointing, okay, let me use the host local selector so that I'm selecting across all of the projects configured over my machine. And let's apply some other conditions like, okay, let's just select the ones that I'm pointing the funding to open collective. So this is the kind of like very, you know, expressive and advanced scenarios you could work and the query language enables you to actually kind of have that workflow available now.

38:22Ruy Adorno:It's interesting that we've seen a similar pattern in many areas of tooling where at first the core base one package at a time problem gets solved. How to dedupe packages, how to talk to a registry. And then, of course, products grow bigger, needs are larger, more complex. And now we're solving problems for workspaces, monorepos, microservices, and micro frontends. And one area that continuously always comes up is security, which I'd like to talk a little bit about with you two. Just looking at your blog post on the host context that you've been talking about, one of the example queries is the colon malware query, which sounds like a horrifying thing to have results at all in your project.

39:01Ruy Adorno:So can you talk about the malware query selector, what it means to have malware detection at the registry and or CLI level?

39:08Darcy Clarke:Totally. So it does seem super scary to run that query and maybe get results. Unfortunately, it's very possible that you could have installed some piece of malware along the way and you don't realize when you've actually done it historically. That selector is actually a mutable selector, which is updating all the time. So the way that works is actually we have partnerships with security insights providers like Socket, in our case, is one of those key vendors that we're working with. And we look at those folks, those partners like metadata providers that we're hoping to enrich your dependency graph with more and more metadata.

39:47Darcy Clarke:So that makes that selector language even more and more powerful for you to codify heuristics into or for your teams or in this case to find potentially vulnerable or insecure packages. So security, we take like super seriously. We have default queries that we're trying to prevent Malware from getting into. But, you know, sometimes these security companies can be slow. NPM has historically been slow to realize that there is malware being distributed. And so it means that there's a active and passive scanning happening. And you can actually opt in to the selector that we have actually called scanned.

40:29Darcy Clarke:And so you can choose to refuse to even install stuff before it's essentially scanned. So this is a beautiful thing where you can say, hey, I'm not going to trust any package. This heuristic to me is important that I actually want to only install packages that have been scanned. And we're providing, which hasn't come out yet, but we're going to be providing a specific vendor, specific scanning selector. So I want to make sure that Socket was actually the one to scan it. And I'm going to wait until they have before I actually consume. So today we sort of mask the underlying vendor by sort of giving these nice, again, primitive selectors like malware or CVE.

41:10Darcy Clarke:And then we give you types, especially for CVEs, the risk type. So in the cases of CWE specifically are the types of CVEs. You can actually put in there something like a Redos, like a regular expression denial of service. That type is like one, I think the number is like 1333. So if you don't care about regular expression denial of service because maybe your developer tool and a package has been maybe flagged for this like inefficient regular expression, which you're like, okay, thank you, SNCC, not to throw shade or purple company, old school purple company that is trying to obviously, you know, protect the ecosystem, but at the same time has kind of spammed our ecosystem with maybe not so efficient advisories.

41:57Darcy Clarke:advisories, you can sort of contextually apply or contextually filter out that noise with these selectors. And so we look at both us providing more and more metadata is going to create, I think, a more secure ecosystem. We don't know how everybody will apply the heuristics to their own projects, whether or not they even consider some vendors to be suspect or not. If they want to opt into some or not. We want to give everybody the option to sort of choose. But there are certain things that we consider to be default. We don't want you to install malware, but it might get on your machine prior to it having been flagged.

42:35Darcy Clarke:So that's just like, how could that have happened? You know, you still want to be able to find it, right? Like, let me easily find it if it did happen. And so we think it is still super powerful for you to be able to do a scan across all your configured projects, like we show in the blog post for potentially malware that might have been previously installed that is now being flagged by any one of our vendors that says, hey, this is malware. So that's kind of how that selector works. And there's more nuances there for sure. Like Socket provides us with some great insights, like whether or not a package has file system access, whether it wants network access.

43:12Darcy Clarke:And we created some nice quick selectors there, like FS and HTTP. And so you can quickly, and also environment secrets or environment access. So you can quickly say, if I do or don't trust a package to have file system access, I can essentially gate that by using CSS's good old not selector, right? So I don't want anything that has file system access, you know, like find me those packages. And we have the override mechanism that you could essentially gate. or we have modifiers as well, which are like our version of overrides, which can get the installation of those packages.

43:52Ruy Adorno:I wonder if you could adopt that system for other concerns beyond just malware. For example, there are community initiatives such as E18E around swapping packages that are older and or slower for say, modern faster packages or just native functionality. Could you add like a colon slow or colon just use node for this now you silly goose selector like that?

44:13Darcy Clarke:Yes. I think there's a couple of things here where we've also flagged the type of package. So if it's CGS, ESM, we have that insight. There are definitely options for us to help with creating variants or distributions that are easily swappable from one to another. We would love to work with the existing maintainers though, so that they can be the ones to kind of control that flow. Many years ago, we actually proposed an RFC for what we call distributions, which would allow for you to have sort of conditional variants of a package. So you could have that full source with all your test files and stuff that a lot of people complain about, but maybe you think is still important to have all the readme docs and everything else put right into your package.

45:01Darcy Clarke:But then you could have that optimized production version that's compiled and has very minimal files inside of the package as well, living alongside each other under the same scope or have some sort of definition that's respected by the package manager to essentially make these two things well understood by the package manager. And so I think distributions and variants are the way forward in regards to that kind of bit flipping or switching between one condition or another. So whether or not it's your environment or the configuration that would tell the package manager that, hey, I can opt into a polyfill because I'm on an older version of Node and I need that polyfill, or I can completely drop that and use the version that basically just stubs out the native API now.

45:52Darcy Clarke:Those are options as well, and we're very close with some of the folks that maintain those legacy libraries. So we're very mindful that they also want the good things to happen. And I won't name names, but certain maintainers that we know of do want folks to modernize and do want folks to get off of maybe, you know, having two or three or 400 dependencies for stuff that is now built into the runtimes. They want to help with that transition as well. So the ecosystem will, I think, evolve over time. But our hope is that we can provide, again, those primitives that would actually help us do innovative things, not just for getting rid of polyfills or getting rid of those types of things, but also provide innovative opportunities for native-specific conditional or natively built variants to coexist in a blessed way versus the ecosystem we have today.

46:45Ruy Adorno:Yeah, and from the end-user point of view, a way to integrate the query language and also between these replacements, it's using this graph modifier feature that we shipped a while ago into the client. So it gives you a way to actually point at a package or a group of packages and replace that definition with something else that is actually, it actually happens during the graph build phase of the package manager. So we do have one already out, which is equivalent to the more classic overrides. And we do have more already planned to add on that graph modifier support in terms of supporting things like package extensions.

47:28Ruy Adorno:I think this is how some of the other clients call it, which basically allows you to define maybe new dependencies at a given package right within the graph and all sorts of crazy stuff like that. We're also granting some extra power to the end user in this entire supply chain. That all sounds lovely. What are some other interesting aspects of Vault that you think users would be pleasantly surprised to discover?

47:58Darcy Clarke:Oh, my goodness. Well, we've talked a little bit about the UI, which Roy mentioned before. And I think that our NPM interop story is quite good. I would say that something that you would be very happy to know if you're a DevTools author or if you're someone that likes this space, we have the best NPM docs that exist out there. I will put my foot down and say we have the only NPM docs that exist out there. If you go looking, you will not find very many NPM registry docs specific. I should have been a little bit more specific. The NPM CLI was well documented from our time there. I would say the NPM registry was never well documented.

48:42Darcy Clarke:And so if you go to docs.vlt.sh, you'll find pretty comprehensive documentation, which gives you obviously endpoints that exist in our registry implementation. But it also provides a quite fairly good comprehensive documentation about what the API surface looks like for the NPM registry itself. The beautiful thing here is we actually give you an interactive docs experience as well, created by or facilitated by our friends at Scalar. If you know those folks, we basically distribute with the registry an interactive docs experience. So when you spin up the VSR instance, you get a slash dash slash docs endpoint.

49:26Darcy Clarke:And there, it's a scalar experience that has mechanisms for you to actually go and interact and actually play with the APIs in real time, which I think is great. So that, I think, will help with folks understanding what's available to them. And over time, it's only going to improve and get better. And so the hope there is that other DevTools authors or folks that traditionally would have wanted to build something for the NPM registry can now be like, hey, I know exactly what the request and response should look like. I know what endpoints should exist. And here, Volt's helping me out. And we're going to maintain, as best we can, backwards compatibility with the NPM registry now and going forward.

50:10Darcy Clarke:So that's another key, I think, highlight that should be exciting for folks. sort of generally about what we're doing and what we're trying to maintain, especially because we care very deeply about compatibility. We care deeply about bringing forward the ecosystem. So I'm not sure if Roy has any key highlights. Go ahead.

50:29Ruy Adorno:Yeah, of course, mine are going to be a little bit more to the client side of things, but it really is the small things that I really love when I'm using it. I mean, of course, the speed, it's very good, but you kind of like, you know, So that's kind of like, for us, it's more of a baseline. We need to be fast. We know people are not going to be using the tool. It's not fast enough. But the little details, like, for example, on the query language, when you're using it from the terminal, default query command, by default, it prints the same tree structure that users are used with from my NPMLS, kind of the classic reference.

51:09Ruy Adorno:For me, personally, that's so much more usable than having the JSON blob be the default output. But also, something we added to VaultLS and VaultQuery is different outputs. Not only the classic JSON output, which is improved, it has all these security insights, metadata added to it. But we do have also Mermaid output, which I find super useful, super helpful. and kind of plugs well with all, you know, plugs well with HackMD. I'm a huge fan of HackMD, like we're using all the time. I can just, you know, copy and paste basically an output and visualize my graph in the rendered view. But it could also be an ocean, right?

51:51Ruy Adorno:It can be a GitHub issue. You could just be porting this mermaid output, whatever platform you want to take it to. And yeah, and I think the other thing I really love is really spawning the browser-based UI, right? I'm trying to understand what's going on. I want to find some information about a specific package and just being able, you know, it's like for me, and I'm a big terminal user, but I do love like, you know, sometimes I just want the product to take my hand, guide me to that experience, just take me to the place, let me find the information I want. I don't want to be typing and finding about, you know, 20 different commands to type, right, to get there.

52:30Ruy Adorno:So for me, those are kind of like top of mind, the things I love the most about the client. That's really exciting stuff. Is there anything else on the technical side or about Vult that we should cover before we wrap up for the day?

52:41Darcy Clarke:I would say we are actively working on the large version of crawling your dependency graph and realizing before you do, which I think, you know, walks that tightrope between the opportunity to both get performance benefits that have never been seen before, as well as security guarantees that are theoretical in a lot of other tools. I won't mention SBOMs, but I just mentioned SBOMs, which are highly theoretical. And we could have a whole episode on that. So I think there's a huge opportunity here. And we're super excited about being at the forefront of it. And we have a lot we're going to be shipping and sharing very soon, both in terms of better performance, better tooling, but also more of a destination for folks to hit going forward.

53:36Darcy Clarke:So look out for that, I guess, very soon. And yeah, we're excited about that.

53:41Ruy Adorno:Well, in that case, I just have a couple more questions for each of you. Roy, what learnings could I as a developer attain from studying and understanding Brazilian Jiu-Jitsu? Good question you may ask. I do practice it. It's been, it's kind of, you know, a recent thing. So I'm definitely not a big, you know, strong Brazilian Jiu-Jitsu guy. I'm just there, you know, to learn and being humbled every time. But, you know, it is a great workout. It is a great way for us developers to spend all these calories, you know. It takes a lot of your muscular strength and flexibility. So it's a very healthy workout for us to try and, you know, and just...

54:28Ruy Adorno:If you're able to get it a couple of times during the week, right? Just getting us out of the desk or chair we're seeing all day long, right? Getting in shape. I've been told that Brazilian Jiu-Jitsu or BJJ involves a lot of strategy and kind of centering yourself. And as three people who actively work on open source projects around the internet, on GitHub, I imagine it's probably quite useful for us to get practice at centering ourselves and regulating our emotions, even in quick response times. Darcy, the last question is for you. Can you tell us about Kurt Cobain's journal?

55:02Darcy Clarke:Oh, no. Yeah. I mean, as a teenager, you know, having been a little bit of a punk myself, I think I got as a present a mass produced copy of Kurt Cobain's journal, having loved Nirvana and being a bunch of punk bands. It's probably the coolest thing, but also felt very inappropriate to own and seemed in retrospect completely unlike something he would have wanted to have exist. So I think we should probably all burn our copies if you have one and let it be. So that's my thoughts on that. Having been a 14 or 15 year old, getting that, I'm sure, I think it was maybe a Christmas gift. It was both cool and insightful and probably shaped a lot of my early garage band days.

55:59Darcy Clarke:But looking back in retrospect, I should have never had access to that thing. I don't think anybody should have had access to that thing. But it was nice to see just how creative, but also how much, unfortunately, it was very pained. I'm also, you know, around the same time, I'm sure I watched Donnie Darko for the first time, which became my favorite film. So, you know, have that on VHS. That also feels like a precious memento of my time as a teenager up in the cold Sudbury, Ontario, small town, cold Sudbury, Ontario. So, yeah, Kirkcomain's journal, let it rest. Let's all burn our copies. Hold on to your VHSs, though, of Donnie Darko.

56:44Darcy Clarke:That's a classic.

56:45Ruy Adorno:That's a great film. Could you just quickly explain the full plot and backing content?

56:50Darcy Clarke:I feel like unfortunately, the director's cut ruined it for a lot of folks. So if you see the original, I hope you do. There was original copy without all these added things. The plot is, there's a bunny in it. There you go. There's a bunny in it. That's all you need to know. It's a beautiful, especially around Halloween, great thriller to watch. And it's one of my favorite movies for sure. and I will not ruin any of it. You can come up to your own conclusions about what did or didn't happen throughout the movie. And that's why I think it's so beautiful about it. So, yeah.

57:27Ruy Adorno:With all that being said, destruction is a form of creation. It's been lovely to talk to you too about vault and package registries and clients. I'll start with you, Darcy. If folks want to learn more about you or vault on the internet, where would they go?

57:39Darcy Clarke:So you can go check out our website of vlt.sh is where the home of all of our information about our company, the clients, products, and we'll put announcements there as well. We put some blog posts out there. You can also follow us on Blue Sky, and it's vlt.sh or at vlt.sh, just our domain. You can also check us out on x.com, used to be Twitter, still is Twitter, slash at, slash or at, I guess, vlt.pkg. And you can also find our GitHub, all our projects, along with a couple extra projects there at gab.com slash VLTPKG as well. For myself, you can follow me again at x.com or Twitter at Darcy, just my first name, which I think is pretty cool.

58:27Darcy Clarke:I'm old. I'm very old. That's how I got that. And as well, I'm blue sky for myself. It's my full name at darcyclark.me, my personal website. So that's how you can find us. Great.

58:42Ruy Adorno:And you, Roy, how about you and the work you're doing on Node? I guess the place I'm more active these days is Blue Sky, so if you want, you should definitely follow me there. It's R-U-Y Adorno. And I think if that's too hard to find, just yeah, like Darcy said, go to vlt.sh, go to the company page that has our names in it, and there are links to social media and then you'll be able to find me there. Excellent. Well, for Software Engineering Daily, this has been Darcy Clark, Roy Adonar, and Josh Goldberg. Thanks for listening, everyone. Have a great day. Cheers.