How 1Password Uses WASM and Rust for Local First Dev With Andrew Burkhart

Welcome to Syntax. Today, we've got a pretty interesting episode on Rust, on WASM, on 1 Password, on all kinds of interesting things.

We've got Andrew Burkhart on who is a senior Rust engineer at 1 Password.

We've been talking over DMs for a couple months. Just kinda I always like to chitchat with people about, like like, what they're doing at their company and and how they're approaching it. And Node password is a really interesting platform because there's so many different places where Node password will live.

There's so many different applications. There's browser extensions. There's Ios apps, things like that. But then there's also, like, there's cryptography and things need to happen locally, and it's a it needs to work offline. It has to happen it has to sync data. There's all kinds of really interesting stuff. So I asked him if he would come on and and talk to us a little bit about how that all works. So welcome, Andrew. Thanks for coming on. Yeah. Thanks for having me. You wanna give us a a quick rundown of, who you are, what you do, and at 1 Password?

Yeah. Definitely. So, like you said, I'm Andrew. I'm a senior rest developer at, 1 Password.

I work on we call it the frameworks team. Naming naming obviously gets hard GitHub, bigger teams, but, we work on kinda like the lowest level of our Rust Scott, so things like, the data layer, some of the networking stuff, synchronization, things like that.

Yeah. I've been here about about 2 years now, but I came prior to that, I was doing pretty much all, like, web back end stuff like, TypeScript Node and, Kotlin Spring Boot.

Right on.

So you wanna give us a a quick rundown of, like, how 1 Password works? Like, I'm I'm sure people have obviously, people know it's it's a password manager. You log in. You put your passwords in there, and then it'll it'll autofill it. I think we understand that part, but it's like a local app. And, like, what happens when you save your password? And let's just use that to sort of frame, the discussion we're having today.

Yeah. Definitely. So like you said, so we have a couple components, but generally speaking, we have, you know, a cloud piece, we have a Rust core, and then we have, sort of like thin clients, you might say, right, like our Bos app or or Android app and so forth. And so that that kinda helps us so that we can, you know, try and squeeze as much into that Rust core as possible so that we're obviously not, you know, duplicating code anywhere we don't have to be and so forth. And then that's kind of nice because you can compile that Rust app, and embed it into all these other apps, but it also does present certain challenges, right, because you're trying to do certain things across different platforms and and so forth. And it's also presented challenges, you know, historically. It's like how do you run, you know, a web app on something like that and so forth, which is something we're working on now. But then, you know, we have this server component that also acts as sort of a you know, it's where we handle all of our sort of data persistence or sync stuff. There's some different things that do have to go through there, like, you know, something we call, like, trusted device enrollment. So, for example, if you have, you know, passkey on 1 device and you wanna go, you know, use on another device, you may have to to verify that or or something like SSO, signing on a new device with SSO or something like that. So so a few things that that server side orchestrates, but we try and get as much as we can into that Wes core to, to make sure that it's, you know, extendable and and, you know, again, we're have kind of maximum reusability of that code.

Okay. Wow. Because, like, I'm trying to think about about using the the one password application. Sometimes they use it via the browser extension. Sometimes they use it as the, macOS desktop app, and often I'll use it on on the Bos application. And if I'm creating a new like, let's say I'm creating a new login, I type in my email address, I type in the password, or it generates 1 for me, and I hit save.

What's the the data flow from me interacting with the input to actually getting, to to 1 password?

Yeah. So that's, luckily, that's kind of my specialty, in here JS, like, the same stuff.

But yeah. So let's say, for example let's just say, like, you have your Mac app open and you have your iPhone open, you know, or something like that. Right? So the way that it works is, you know, on your iPhone, you're interacting with an Bos app, a native Swift app, and then that's going to, do whatever inputs there. That's going to, send what we call an invocation, which is basically like the the mechanic for making requests from the client app to that embedded Rust warp.

And that's kind of its own little cool bit of Rust that does, like, it kinda has, like, this loop that sort of just watches and receives from a channel and, you know, there's some serialization, deserialization that goes on, stuff like that. But, anyway, it ends up processing this task asynchronously that front end app will also pass in a callback. And whenever the core is done processing that, it will execute that callback with the actual data that it's collected as the response. That's the same way you'd get info or create info or anything, but then that core will go through its server client.

Once it's done storing it locally and everything, we will basically tick local ad account and say, hey. There's something here that's that's got a modification. Right? And it will, start a sync process. And so what happens is it reaches out to an endpoint that we have on the cloud side that goes, hey. You know, we have a change for this, but give me the kind of the state of the world. Give me all the versions of everything for this account.

That's gonna pull down, you know, here's this list of vaults that you have and all the content versions and things like that. And then it's gonna do some local resolution. So it's gonna go, alright. You know Node? That, you know, there's this other vault that's got some edits that I don't have, so I'm gonna pull all this stuff down and then I'll push my stuff up when I'm done. So it's always pull first and then push. Okay. That does create, you know, some some unique challenges, right, for for two reasons. Node, because you might have have an edit on the cloud, just something that I just did. Right? Mhmm. So you gotta do some conflict resolution, and that gets tricky because of the, you know, like you mentioned before, like, we have a a unique problem space, right, where everything on the server has to be completely encrypted. The server has to be completely Deno to all the contents.

So what that means is we can't have the server do conflict resolution at all. Doesn't have any access to that data. It can't see anything that's going on. Wow. Yeah. All we have is, like, a content version and, you know, an ID or whatever. And there's a there's a few different versions. Right? Like, there's a version of, you know, the access list for this, things like that, so that we kind of know who can see what and so forth. But that's the biggest issue we run into with this kind of sync process is the server can't help. It's completely blind to what's going on. So everything has to go to the server and then get pulled down to the device and do conflict resolution on the device before we actually push those changes back up to the server JS kind of the new, source of truth.

That's wild. So, like, yeah, you usually, you think, oh, yeah. We'll have a single server, and that will do that will be a main spot for it. But you you have 1 password has no idea about what our passwords are, So it's it can't compare email addresses or or Exactly. Usernames.

So you have to do it on device. And how do you decide which device to do it on?

It so it depends. Technically, they're all doing it, to some degree. Okay. We're because of that, we're a little bit we're a little bit cautious about it in terms of, like, there may be a point where it's like, ah, this can't be reconciled. Like, you're gonna need to, like, manually figure this out. You know, we wanna make sure with with the subject matter we're dealing with that data loss is, like, unacceptable at any point ever. Right? You can't afford for that at all. So because of that, we'll never, like, take a chance on trying to merge something that we don't know can be merged.

But there's a few, and this again goes into kind of some neat Rust stuff, but, like, we essentially have a trait that is, like, merge strategy And whenever you save data locally, you have to pass in a trait object that defines the merge strategy for this data. And so, you know, there there might be one that's like save wins Bos, basically, that's just like last edit wins. Like, whoever added it most recently, you know, gets this and that might happen in certain scenarios, or there may be some that are a little more little more cautious and are are, like, if there's any kind of, like, collision that we see here, just, like, pass it back. It's like we don't know. You know? It's not like an amazingly complex conflict resolution system, but it is Mhmm. It's much more of a concurrency or distributed problem than it is the actual, you know, resolution piece. Wow. That's that's really interesting. We've been talking a lot about CRDTs and Local First stuff on here, and syncing is such a big

big part of that. And it always feels so daunting.

And that's all being done within the Rust component you send? That's Yeah. That's pretty amazing. You know, the one thing I really admire about the 1 Password app is that my data is always synced without me ever having to do anything. It's always there, and it's always correct. I never have to worry about it. So whatever you guys are doing, it is fast, and it works. Yeah.

It's good. I've noticed it getting, like, faster lately. Like, I will sometimes have my kid's iPad open. I have my 1 password on there. Or, like, I'll have, like, I'll try to autofill something on a website, and I'll go, oh, it's it's using the Scott version I'm trying to sign in to Amazon Node. So I'll go into 1 password. I'll add Amazon Node to allow domains, and it will it will pop up immediately.

And, like, how how do you do that so fast? Is there is it WebSockets or something?

Yeah. So there's actually a few ways. And this is one of the things we're trying to reconcile right now. Right? It's like the Rust core, it's not easy. Like, it's easy when it's islands. Right? You just go, hey. Compile this and then link it, you know, as like a, you know, your c headers and everything. Right? No problem. Doesn't work like that when you have a TypeScript app. Right? You can't just, like, pop this in there and go, hey. This is great. Like, so we're working on that. But that means there's a couple different ways. In general, kind of the main sync, you know, strategy or architecture, whatever, and this is kind of, like you said, where my focus JS, you know, we have this push pull local sync strategy. Right? We push our changes up. The server handles, you know, validation and storing and all that stuff, all the complex, you know, data storage that you have to have with large scale. And then it basically sends a ping to another service that that I work on called the notifier. And the notifier, every 1 Password app, each time you unlock an account, that account connects to the notifier. Basically says, like, hey. I'm online.

And then the notifier, whenever it gets one of these changes from the server, will ping all the connected clients that need to know about this change via this WebSocket connection, and then you'll trigger one of those sync jobs again. And so you can you can actually I mean, you can imagine, right, with a company that's got, let's say, 10,000 people that may all be signed into the same account, you can have a lot of edits that are going out at the same time. So there can be a lot of things going out. So there's some cool, you know, Node, debouncing stuff, that we do on the notifier side, which just kind of a microservice.

And then, you know, we do some debouncing stuff even on the client Node, right, because you might be getting multiple of these pings for different reasons. So we'll actually, like, enqueue different, sync jobs that need to to run kinda once it's their turn. But that's the main sync flow is is the notifier will get a ping from the server saying, hey. Something changed. It will let the, device know with a ping and the device queues up one of those sync jobs, which is just that pull, push mechanism that we talked about. There's some nuance when it comes to a few other things, for example, like the extension.

So autofill, you know, from the extension can can work a little bit differently because it's kinda got its own database in a way that does, like K and N stuff, because it you know, for autofill, like, we may need to know that something is of like, there is a password for this, but you may not necessarily be unlocked. So the actual data is not decrypted at the moment, because everything is stored locally encrypted as well. It only decrypts while the account is unlocked and then gets reencrypted. So which just syncing key sets for, that can be its own, little fun area of sync. But but yeah. Like, so something like autofill has to have its own little table for K and on stuff so that it knows, hey. I've got something for this, but if you're gonna actually use it, we need to go unlock or something like that. So there's a little bit of different syncing that goes on there, like the example you mentioned where it's like, hey. I added a domain and my extension knows about this now. There's, like, some rebuilding of that table that's gotta go on and so forth, And then there's some some connection that the browser extension can have with an unlocked desktop app, for example. So there may be some different syncing that goes on with that. It's crazy because you don't necessarily think about well, I mean, there's all these little intricacies that you don't think about. Like, you mentioned, you had to know if the site knows if it has a password. But even as far as, like, getting into the WebSocket,

the syncing conflict resolution, they're it's so funny because it feels like these problems show up in all these places you might not expect. You know, you think about real time and syncing. Oh, yeah. You're building a a chat app. You're building but, no, it's it's a one password. It's a a password manager. Man, that is so cool. Wow.

Yeah. We actually we do these internal hackathons.

So, like, I think it's quarterly or something like that. Couple times a year, we'll do these hackathons, and they'll just give us a theme that's like, alright. This time, it's, you know, accessibility or this time it's, you know, impact and efficiency or something like that. Right? We'll, go into this notion and throw some ideas in there, and everyone will just join teams. And we'll just build anything for, like, 3 days, whatever we feel like. Doesn't matter if it's got any commercial viability whatsoever. But because we have some of these things in place, someone actually built 1 Password IRC as their hackathon project. I think they actually posted on LinkedIn a video of it or something like that, but they made 1 Password into an IRC client.

It was pretty cool.

That's great. So with 1 password using Rust, like, what's the benefit there?

Yeah. I mean, we get a few things out of it. Right? So the first one being, you know, the cross platform nature of what we're trying to do. Right? We're trying to embed this core in different places so we can just compile this to different targets that, you know, come with the language and everything. It's pretty easy that way. That's one of the nice things. The second nice thing that we get out of it is just the safety. Right? Like, obviously, everyone always talks about memory safety with Rust, and that's pretty critical for us. Comes down to even things like 0ization.

So, like, when we deal with memories, like I I mentioned, right, we we decrypt the database when you unlock, so that you have this data available.

But when we're done, if something's been loaded into memory, we can't just, like, forget about it like you kinda normally do with most languages. Right? We have to manually flip those back to zeros to make sure that that memory doesn't sit around. So that way if someone's Oh. You know, let's say someone's traveling internationally or something, right, and they get picked up at the border and they flash a device or something like that, we need to make sure those were already zeros. Like, we we can't have that just sitting there for someone to find later on. So, you know, we have things like travel mode for that, but, yeah, specifically, being able to manually manage that memory so that we can flip everything back to zeros and make sure that we are covering all the possible bases, is is pretty critical for us.

Wow. I didn't even think of that. That's they have to think about Scott the passwords just being encrypted, but the the password possibly still being in memory of the system.

That is wild. And then we obviously get, you know, performance benefits. Right? And that's not you know, that conversation can go on forever about what's best there. But, the, you know, the performance benefits we get, like I mentioned just with sync. Right? You might have some sync jobs that are pulling down all kinds of data, trying to do conflict resolution. That's all happening in the background where you're still using the app maybe. Right? Like, you may be doing other things. You may be trying to do a search. So we've got 1 thread that spins off that's doing your search and then we Scott another thread that spun off handling the sync job and, you know, you maybe have just TypeScript. So, like, there's a lot of things that can go on. Right? And so making sure that we have the ability to handle really a lot of complex information. You know, calculating watchtower scores, right, while you're trying to do, you know, something in the background or something like that. They can definitely be be a pretty performance heavy, you know, application with all the stuff that we're trying to get done. So Rust definitely helps us there, and I'm sure there are other languages that could, you know, match the performance different ways and so forth. But Yeah. With those other benefits, it just makes it a really nice, you know, abstraction over all the problems we're trying to solve.

Yeah. The Watchtower Scott. That's really interesting. So if you don't know, it's Watchtower will will tell you if you are reusing any passwords or if your password's been involved in a compromised website, things like that. So that's being calculated

on the app when I'm when I have it open. It's JS I think Bos not on the watchtower team, but I actually think it's being calculated every time you click on the watchtower tab, if I'm not mistaken. Wow.

Because that, you know, that can change at any given time. Right? And it can because they I mean, Watchtower is growing too. Right? Like, now it'll tell you, hey, this website supports passkeys, and you're using a password still or things like that. So there's all these things that, you know, Watchtower tends to do. And then in, you know, in a business use case, it's even more powerful in a lot of ways, right, because you're trying to manage, you know, governance and things like that. Right? And so Oh, yeah. So, yeah, Watchtower's pretty powerful pretty powerful little section.

It's one of the best features of 1 Password for sure that and even just Node, I popped it open, as you said, that one of the new things on here. Developer credentials on disk. Check your local disk for developer cred man, I've never seen that. That looks brand new.

There there's so many cool developer tools, and this is where I feel like, I always feel kind of undereducated, I guess, even on our own developer offerings. But, like, you know, I got here. I've been at 1 Password for a little while, and finally, it was like, see everybody talking about these other things? Like, I need to like, I don't really need the, you know, 1 Password CLI tool, let's say. Like, I don't don't really have any workflows where I use that, but I know it's cool. Like, I've seen some stuff with it. But then it was like, we have this SSH agent.

And so I finally was like, oh, maybe that's gonna be complex. I don't know. And then I set it up. It literally took, like, 2, 3 minutes to set it up, and I've never worried about SSH ever again. Like, everything just pops up after my fingerprint, and I'm done. It's like, this is great. Awesome. It's amazing. Oh, really? Oh, yeah. Yeah. It's incredible. I highly recommend the SSH agent. It, like That's my number 1. I hate that going you every single time I I I I type pnpm SSH, I'm like, oh, shoot. Where which password is it? Where do you go? Oh, no. Yeah. I know. It's a total mess. Wow. That's Especially when you have, like, you know, signed commits. Like, we require signed commits even for, like, our our open source rebuilds and stuff like that. And so just having that all built in is is amazing. Oh, because

I have used the Node password dotenv, and I I'm trying to move everything over to it because I'll explain what it is for everybody listening is, you know, you have, like, a your local dev and you you make a dotenv file, and you put your your database connection strings in there and your your API keys and and all that stuff. And first of all, it's a pain in the ass to manage because it's just a text file. And second of all, like, yeah, you put it in your git ignore, but you probably also shouldn't just have those keys, hanging around on your on your in a text file on your computer. So you can run the o p CLI command, and it will then inject the environmental variables into your, into that instance.

And then you can just go ahead and use them with the process dotenv dot whatever.

Oh,

that's fun. Really cool. Man. That's pretty awesome. They have a few things like that. We have, like, again, some I'm not not particularly well versed. We have, like, a Scott bridge that handles, like, you know, being the middleman, some of this identity management stuff.

You know, there's, like, the connect servers and, you know, secrets management and all this stuff. There's so many cool little tools where it's like it's just these neat little additions to the core concept of managing passwords, right, that Yarn, you know I talked to someone the other day who was like, I do all of my notes that, they they're journalists. They're like, I do all my notes in 1 password. Like, all my storage JS in there. And it was, like, just because it's encrypted by default and you don't have to worry about any workflows or anything. It's just right there. They use the tag system heavily.

There's just a lot of little, like you know, obviously, I'm biased. I'm working here, right, but, like, you know, there's a lot of neat little, like, use cases. And even one of the things I had never used it till I got here. One of the first project I worked on was our Apple Watch project for, 1 Password 8 because when we first moved from 7 to 8, we didn't have the watch app, and people were sorely missing it. So we tried to get that get that out to people, and it was just interesting seeing all the different use cases where people were like, oh, we have doors in our building that have a rotating code, and so we have now I have it on my watch, and it, like, shows me it JS one of my watch complications, so I can just you know, it's really easy. And, just like I never would've never thought to use that,

even being here. It's pretty cool. Yeah. I I mean, I've put a lot stuff in in 1 Password from, like, driver's license to all of my kids' passports and stuff like that. I I wonder, personally, you know, given I think there's some recent not Sanity recent. Who is it? The other password Node. Lastpass had some security issues.

Yeah. Is that like, given the nature of what you work on, are you ever concerned about the intense security in which everything exists under?

Yeah. I mean, that's it it's an interesting one. Right? Because, you know, it's Sanity. Like, people would talk to me, and they were like, oh, that must be great for you guys. I'm just like, not really, to be honest, because I think mostly most of us in this space tend to think of it as like people are using a password manager or they're Scott, and most people aren't, right? Like, so we kind of all, I think, still see this space as being a bit in its infancy. Like, it's at that phase where we're still trying to convince people, like, you should be doing this.

And so, like, you'll hear I mean, even I I think even Jeff Schein, our CEO, at one point was like, just use 1. I would love it if it's us, but use 1, please. Like Yeah. And so there's this, like, consensus that it's, like, what happened with LastPass was unfortunate, but but I think everyone in security tends to operate on the standpoint that, like, breaches aren't an if but a when. Right? Like, the way things work now, like, there's so many crazy things that can happen. You see these people that spend so much money on it and it still happens, and it's, like, there's always something. So that's why, you know, like I mentioned with with the sync system, like, everything on our side, even our metadata, which is what would kind of protect us in the last Bos scenario, our metadata is even encrypted on the server side. So, like, you know, again, there's, like, some version numbers and stuff, but, like, you know, something like autofill, like, we don't store there's no URLs on the server. So if you get into our server and you get into somebody's account, you're not gonna find anything really all that useful. You know? There there's you're gonna know maybe how many times they've edited a vault, I guess, would be the most useful info, but that's pretty limited. Right? Like so it's definitely something we think about a Scott. And it is something, you know, I mentioned, right, like 0ization. Like, the threat model that we're trying to work within, it's you know, I think, like, when I think about 1Password, for the most part, right, it's like, oh, it's my Netflix. Like, if someone gets my Netflix, like, you know, it's not a huge deal. It's unfortunate, but whatever. Right? But there are a lot of people who are using this for, like, critical scenarios, you know, businesses that are using for things, people's bank accounts, like you said, passports or driver's license, like Yeah. There are a lot of really intense situations that come up with this, and it's it's something where we I think we do have to kinda balance it, like, from a, you Node, almost like a mental health standpoint, I guess. Like, you have to balance the intensity of what you're working on and the sort of, you know, knowing that we can't really afford for mistakes. You know? It it's just not something that we can have, and we try and build that in mechanically as much as possible.

But also balancing that with, like, you can't operate under that 8 hours a day for that many years. You know? Like, that's a lot of a lot of weight, in a lot of ways. And so yeah. I guess that's a bit of a ramble, but to your original question, yeah, like, it's something that I think is front of mind, but also we try to just move that to a mechanic as much as possible.

You know, for example, like, we in 1 Password's, app, you can't log dynamic strings by default. It's all blocked. So everything is built in mechanically so that, like, I can't go, you know, x equals 7 and then print x. It'll be like, nope. Can't do that.

So we actually have a macro that allows us to log things, but everything that we wanna log that's dynamic has to implement the specific trait that we have that makes it loggable.

And anytime you wanna add loggable to something, security developers are gonna come in and review that. We have some scenarios where you can, like, you know, make some assertions, but, again, if you use that, security developer is gonna come in and review that. So, like, you know, there's there's just a lot of stuff that we try and bake right in that make sure that mistakes are really hard to make. It's really hard to, like, slide stuff by.

And it's, you know, easier and harder depending on where you're at in the stack. You know, the closer you are to the client, you kind of have more layers of abstraction to the point where something would happen, but, yeah, I mean, it's it's definitely something that's all over the place and it it you know, we definitely lean more on security than productivity.

Like, we we probably slow ourselves down significantly in a lot of ways trying to make sure that we don't break things. You know? We go through very long nightly in beta processes before a release really goes out and or even tries to be cut,

to make sure that we have really deep QA testing that's gone on the back of our deep CI pipelines. It's gone on the back of all these mechanics, and so, yeah, it's it's it's definitely a huge part of what we do. That's wild. What's the, like, onboarding security training look like at 1 Password? Because we have to do it every couple months at Sentry, and it's like, don't plug USB sticks that you found on the ground into your computer. And you have to, like, take a quiz about, like, what should you do if you find a USB stick? Like, plug it in your computer.

Right.

What does that look like at 1 password? I assume it's it's massive.

So, honestly, I think it's probably not as intense as you might assume. Node, because there are so many mechanics built in. Right? The third, like systems is better than trying to tell people don't do this.

But there is a lot of, you know, education that's gotta go on. Right? We have a we call it 1 Password University. I think it's actually got public facing component too. But there's, like, you know, employees can log in there, and there's all kinds of training that we do during onboarding.

You know? And that that's not just security stuff. Right? There's human resources things and and so forth. And then we try to kind of slow play people into whatever they're doing here so that it is a lot of kind of onboarding buddy type system to make sure you Node, I mean, even just like we we brought in someone recently who's a senior Rust developer who hired in, and it was somebody who knows Rust very Wes, but when they get into the core, it's like, oh, there's a lot going on. Like, there's a lot of domain knowledge, you know, and, like, you know, why did we build things the way that we did and so forth. And then you get into, you know, something like 1Password's been around since, you know, I think it was 2000 five or something like that or coming out 20 Yarn, you know, there's a lot of historical decisions that are still around, you know, as it tends to happen with anything you build, And so there's just so much context to everything you're doing. So security training kinda gets baked in throughout, but we also have, you know, we just 1Password recently acquired Collide, which is a tool that runs on the local system and it checks things for you. Right? Like, you know, are you following basically the company policy for device security to make sure that, you know, hey, you you don't have a sleep timer set, like, you need to update that, or, hey, you have an old version of Chrome that's vulnerable, you need to make sure you update that, like, so we have a lot of those things again. We try to, like, bake in, you know you you always say hear that phrase, right, like, pit of success. Like, you should always make the right thing the easy thing, and so we've tried to lean into that as much as possible. Right? Where it's like, let's just make the normal way the way that's already secure, and then we're good. You know? And, like, we'll we'll try to teach people these concepts as well, but, it's definitely baked in pretty heavily.

Cool.

Let's talk about the WASM stuff. I know you're starting to dip into to what this JS, and, obviously, you wanna run Rust anywhere.

The web is is going to be one of those places or is already one of those places?

I believe is in beta, for our web app. I don't have any dates necessarily. I think it's still TBD on some of the, you know, official releases and so forth or stable releases.

But, yeah, that that is the idea. Right? So we're, we've kind of had these client apps, which is the category of apps that run on top of the embedded Rust Core, and then the web Mhmm. Right? It's kinda like this other thing, you know, and it's kind of always but because of that, you know, you do that for years and then you end up with a lot of these things that are, like, really similar logic, but they're forked a little bit. You know? And it's just enough that it's hard to bring them back in.

And so we've been looking at that a lot. There's a team that's been working on that, and we've been we've been consulting somewhat on that, just trying to trying to help keep an eye on all the pieces. Right? Because there's so much going on and trying to figure out, like, you know, for so, for example, the way that our app worked historically was, like, they're, like, from a code structure standpoint JS, like, there's this app that kind of represents the back end on the Rust side or this crate, I'm sorry, that that represents the back end on the Rust side. So it's got this Yeah. Of all the invocations you can make. Like, what are all the requests you can make and their types and so forth, and that allows us, you may have seen we have a tool called TypeScript that we open source that basically you can annotate any Rust struct with TypeScript, and it will spit out the TypeScript equivalent or, you know, whatever it is. So that's how we share types back and forth. But, anyways, we have this big back end crate or or file, really. But that means that when you compile this, if you compile that file, you compile everything that that file links to. Right? Just the way that that tree kinda spreads out. And so you end up compiling the whole universe if you want anything. Right? And so we had to modify that. It was like, alright. Let's let's pull some of these things out into, like, reusable services, and then we'll have multiple app crates that actually represent the apps that are consuming these things. So that way, something like the browser app that doesn't necessarily need everything, especially as we move, you know, piece by piece. It only does a couple things right now from the Rust core. So let's just link up you know, we'll make an accurate that just has the things that we need in this pnpm so that way we're only compiling that code and, you know, the size becomes significantly more manageable, at that point.

And that that comes into everything. You know, you Scott make decisions, right? Like, so our our core runs heavily on Tokyo.

You know, the async runtime, and and that's how we handle all of our futures and things like that.

But it doesn't line up really one to 1 with Wasm at the moment. It's a little bit bit tricky.

And so we were building something the other day where it was like, do we you know, we have a scenario where we need a future. Right? But do we sort of take a smaller crate, like futures r s? Or do we just hand roll a little future? And it's like, well, hand rolling your own future is kinda complex. It's not something you'd usually wanna do. But if it can avoid, you know, 14 kilobytes or kilobytes or whatever they are, like, is that worth it? And it's like, I've just never really operated in such a, like, size constrained, you know, area. And so it's like, you know, I have to go and be like, I don't know. That's it. You know? I have really no no guidance whatsoever. I have no idea.

You know, is that a lot in WASM? And it's like, some people are like, yeah, it's a lot. It's like, well, how big is the binary? It's like, well, you know, it depends, and we're working on this and trying to get smaller. And so size just becomes so much more constrained, whereas, like, in our, you know, space, historically, working on the core, it's been much more about resource constraints or are we draining battery with sinks or, like, you know, Apple Wes we first built Apple Watch, it was like, we could do it like this. This would be really efficient, but it's Scott constantly pinging. And so the battery just disappears. And so I was like, yeah. That's not gonna work. And so, you know, size is just not really the constraint that I've I've operated within. So WASM's been a whole new interesting area for that.

Interesting. So Tokyo is the runtime for writing asynchronous Node. Like like, imagine JavaScript async await, but in Rust, and that's what you call it features. Right?

Yes. So it Tokyo is sort of the de facto crate. There is, something called async std, in Rust. I just and I think that's the standard library one or something, but I I've never really seen it used that much. Tokyo is kind of like the the main player in that space. Yeah. That's what Deno JS built on. Right? I think so. Yeah. It's kind of a collection of really cool stuff. So Tokyo has Tokyo, which, involves, you know, runtime and some methods like spawning on this runtime and so forth. It also has some some other pieces. Right? Like, there's, I think it's called Mio, which is, like, their actual, like, IO, implementation that handles async IO from the operating system level.

And then there's, tower, which is basically defines this service trait.

And then you've got Axsome, which is like a web server thing, which Axum is kinda cool because Axum is this really thin layer that basically lets you define middleware as long as that middleware implements this tower service trait. Mhmm. You can build anything you want or use anyone else's. And so it ends up being this really interesting combination of little crates that come together to build a whole Oh, cool. Sort of async or concurrency ecosystem. It's really powerful.

There's a ton of really interesting stuff. And just like I said, coming from my background with, you know, web where it's like, hey, or you have a main function or you have, you know, whatever it is. Right? But with the embedded back end, my first thing that I got here was like, how does this run? Like, how does it know to wait for a request? Right? Like, it's one thing, like, it always made sense to me. Like, oh, I have this add function. You give it 2 integers and it spits 1 back out. It's like, well, that's just compiled and it's waiting for you to call it. But this thing has, like, listeners in the background. There's all this stuff going on. It's like, how does it Node to, you know, or how does it stay running? And Tokyo is actually kind of the mechanism for that so that watching for those invocations, we basically block, particularly, like, we spin up a thread and then we block that thread watching a channel.

And every time somebody comes in on that channel, we process it and it spawns its own tasks and so forth.

But then we hand that channel off to the main app and the main app, you know, basically processes these things as they come in, and we hand off the sender of all that to the FFI.

So then whenever they call invoke over this FFI, it puts something into that channel and it goes to the whole mechanics, but it's really kind of like a it's a really interesting way to, you know, run,

this embedded back end sort of thing that we have in there. It's pretty neat. Wow. Yeah. I'm building, like, a video app in Tori with Rust. And the moment I installed Tokyo was the moment I was like, alright. I'm I guess I'm getting into Rust. Yeah. I'm No kidding. This is the thought. Yeah.

Oh, that's cool. So in in your app, Scott, what are you are you using it for? Like like, at what point did you realize you needed that?

Yeah.

So accepting various streams of blobs of video and then writing them to files, Yeah. That that was pretty much it. It it was Okay. I have, yeah, multiple streams coming in and being able to write them to files.

Yeah. And that's super interesting. And I I just say really quickly, Andrew said FFI. That means foreign function interface.

That means calling a Rust function from somewhere else. Am I am I right about that? Yeah. Yeah. So you have to basically,

you know, we have this Rust app. We're trying to embed it, let's say, in an Bos app. But we need a way for Swift to know how to call that function.

And the FFI is where you define basically, they call it the calling convention. So over this function, I might say, like, this is an external function that's going to have the c calling convention.

And that's going to tell the actual, like basically, like, how you actually organize this memory. It needs to have so many bytes for the name and so many bytes the argument, so many bytes for this. Right? And that's that's kinda how it it winds up all those things.

So how is this all connected to the UI here? So you're shipping an app. What's the UI built in? Is that built in Wes tech and then,

yeah, connected to browser side? Yes. Yeah. So each app Wes try and have, you know, as as native as possible, basically.

So the browser app, yeah, it's a React app that and this is actually be kinda interesting. This is a new new area for us as we as we migrate. You know, we need to make sure that this app has certain amounts of data, and there's some, like, identifying challenges that can come, you know, crossing that boundary from the client app into the core. So we actually have a Redux store on the client Node, and then one of the the guys on that team built, basically, a bridge crate in the core that gets all the Redux selectors and can pull stuff back into the core from the Redux side. And then we have, like, some kind of a sync process that goes on from the core side into that Redux store to make sure that the Redux store is constantly updated.

But it's it's interesting, like I said, because you go into WASM and it's like it doesn't really sort of support the multithreading in the way that we're used to. I know WASM has, like, worker threads or whatever they're called, but it's doesn't doesn't quite work the same way that the other ones do. And so it's a really cool mechanic. Again, it's Scott of probably a temporary mechanic as we, you know, we shift it to be more and more of just using the normal core, as we get there, but it's a really cool way to to sort of, you know, federate that data back and forth.

Wow. Man, that's wild. Like, you think you you think you know a thing or two about software development, you hit an API,

saying variables

Yeah. Putting the variables in a div. And then you're like, you talk to people, and it's just like, there are so many different problems out there that are are being tackled in in all these different ways. It's just fascinating to hear. I make button with CSS.

Yeah.

I'm like a caveman.

You know what's funny, though? It's, like, doing all this stuff. I still couldn't put a button where it needs to go to save my life. And I was a front end developer for years, and I couldn't touch CSS. Like, if I was working on a Vue app, and we used Vuetify.

And, the designer sent over design. I literally sent back, like, sorry. That button doesn't exist in Beautify. You're gonna have to pick one of these options, and I sent them the link to the Beautify docs where it was like, you get extra large, large, or medium. Yeah. This is Like, sorry to see your options. I don't know what to tell you.

It's so funny. Oh, man. And how did you pick up Rust then if you have, like, a a JavaScript background?

I was doing, like I said, like, server side stuff, but I knew I kinda wanted to I don't know. It almost sounds arrogant. I guess, like, step up into kind of another level of engineering stuff. Right? Like, I'd worked at a marketing agency and an ad agency and a health tech company and stuff like that, but it was all kinda like smaller stuff. You know? So I wanted to jump into something that was way more intense. You know? I was gonna knew it was gonna push me. And so they had an opening for a Rust developer, and so I got through the 1st couple rounds or whatever, and then I get to the technical interview.

I went in to this interview. It's actually with 2 guys that I I still work with, Ivan and Mathieu. And they, pull up this, like, playground Wes playground with some code in it. They're like, alright. Just walk us through this. And I'm walking him through, like, a few minutes ESLint. Mathieu JS one of the nicest people ever. He stops me. He's like, I'm just gonna ask, have you ever done Rust before? And I was like, I've never written a line of it in my life. This is my first time right here. And he was like, okay. That's fine. That's good context. Now we know. You know? So, like, basically, they gave me, like, 2 or 3 pointers. I walked through what was going on. They were like, that was pretty good, like, you know, considering you didn't know it or whatever. So I get they eventually hired me, obviously, and I get here, and my boss Bos like, considering your background, we're gonna give you a couple months to just figure this out. And I was like, Wes so they really I think I got, like, 3 months of basically just, like, learn, play around with stuff.

Like, if you wanna try and tackle tickets, do it, but don't even worry about if they ever merge. Like, just figure it out. And so I got a couple books, and John Yangsitt is a guy who does YouTube stuff for Rust. Mhmm. Highly recommend. Extremely extremely useful stuff. He goes everywhere from, like, some of kinda like the mid level Rust learning stuff all the way into he does a series called Node crusting Wes he'll go into some, like like, Axsome, for example. So go into Axsome, and he'll be like, alright. We're gonna go all the way to the bottom. Like, we're gonna dig through the source code of Axsome, and I'll explain to you how every piece works. That's cool. Really awesome. I mean, to this day, I've been watching that stuff to to really learn a ton.

But going through him, there's another channel called Let's Get Rusty, a guy named Bogdan.

He kinda goes through the Rust book chapter by chapter and explains some of the concepts and shows examples. So it's really those 2 YouTube channels and a couple books and stuff like that. We actually have a Rust study group at 1 Password too. That didn't really start till after I had got here. There's a guy, Tanner Gill, one one of the developers here, started a Rust study group, and so I jumped into there, and that helped me a ton.

Honestly, it was it was immensely helpful because there's a lot of really elite Rust people here. Like, one of the Tokyo maintainers works here. There's a few other big crates that are maintained by people here. Just a lot of knowledge, and so it it was massive to getting me, you know, where I am now. I actually ended up taking over the Rust study group for this iteration, and just trying to kinda give back on that one because it's been we have I think we have like 130 people in there, and it's everywhere from like developers of other languages to like CSS people. I think we have an account manager type person, and, like, there's all kinds of stuff we're trying to How many people work at 1Password? There's over a1000.

I could build it in a weekend. Yeah. Right? Yeah. It's you know, it's so funny because you're like you said, it's so funny when you look at on the surface, you know, it's password. Right? Like Yeah. There's other there's other ones around, you know. And then when you get into it and you're like you know, again, there's an entire team for security engineering and a separate team for security development.

You know? And then you've got, you know, everybody that's gotta handle all the data federation, you know, which, again, kinda how I refer to our team.

And then, you know, you've got some people that are handling item management. Another team that's handling onboarding and activation stuff. There's another team that has to handle observability and experimentation, a team that's Scott do all of our UI components. We have, like, our own internal library of components. Like so so there's all these people. And then you look at the depth of the features that exist now between things like Watchtower, but things like the CLI tool, things like our open source creates, you know, things like our we have a team that does platform advancement, which basically just means this is a team that knows all the actual platform mechanics inside and out. So there's a guy over there, Neil, that just says Windows stuff, and he just knows how Windows like, the quirks of Windows inside and out. And so when we have these weird networking thing that only pops up on Windows, Neil knows how to fix it. You know? And Yeah. There's just so much kinda surprising nuance, I guess, when it comes to making something like this and, more importantly, making it, you know, efficient, useful, and safe.

Wow.

I I always wondered that. Like, how many people are working there? Because even, like, my bank, my bank's mobile app did something where the 1 password was no longer prompting. Like, they changed the input type or something weird like that on the Bos app. And I I tweeted at them, and they're like, hell, have you tried uninstalling and reinstalling it? And I was like, no. That's not the problem. That's I was like, thank you. You're a no help. So then I I, pinged 1 password, and I'm pretty sure they literally walked over there and kicked some butt. Yeah. Mhmm. Like, I'm sure like, is that a team in there as well, like, contacting people who run apps and say, like, hey. You 1 password broke on your app or or is no longer being prompting?

I would guess that someone does that. I mean, we so, like, so we have a team that does, filling and saving specifically so that there's a team that is specifically focused on filling and saving across all the different platforms and so forth.

And I've just like, again, that that area, they end up dealing a lot with web stuff, which is where my mind always just gets blown by, like you know, again, they, you know, they talk about things like focus traps, right, where, like, there will be scenarios where, like, you'll, you know, click on the thing and then it pops the pop up back up again even though it's already got it there. You click it and it doesn't actually fill in, and they're like, oh, yeah. Well, here's all these scenarios where the website developer can actually completely block us from being able to do anything from the extension. Mhmm.

And it's like, oh my gosh. Like and then, of course, like, to a user, it's like, One Password's not working because that's what it looks like. You know? Like, there's no how would they know? You know? And so it's like, we have all these areas where it's like being internal to a company like this, it just makes you whenever you see stuff on Reddit, you're always like, we're fixing that. Oh, we're fixing it. It's like you know? Or, like, we're trying. I swear.

Yeah. It's, it's a challenge, though. I mean, the web is so hard.

It's like when I look at Rust stuff, people will say, like, Rust complicated. I've been saying this a lot this week because I had to fix how we registered a service worker to, register the the browser for push notifications.

And I haven't touched TypeScript in years. I've never done service workers. And so I was working with one of our TypeScript devs getting in there, and you're just like, oh, you can't do that. So this this blew my mind. Maybe you already know this. I was having issues with the registration because then Node try and do something and we would get an error, and it would be like, oh, there is no service worker register. But if I waited a second, it worked. And so I looked at the docs, and it says like, this was like the, you know, MDN docs or whatever. And it was like, the service worker dot register function returns a promise that fulfills as soon as it's clear that it's valid JavaScript.

Responding or resolving this promise has nothing to do with whether or not the service worker has registered.

So it's like the register functions promise doesn't actually tell you whether or not it registered, which blew my mind. And so I kept messaging. We're like, they say Rust is hard. You know? Like, the web is tough. Like, there's so much. And I feel like Yeah. I feel like front end devs kind of get, like, shade in general for, like, oh, it's not, you know, systems programming. It's not kernel development, right, or whatever. Right? Like, it's kind of seen in a lot of ways JS, like, this, like Yeah. Lesser area. But then you see all this stuff, and you're like, oh, no. When I write Rust stuff, it just works. You know? Like, it's tough to get it there sometimes, but then it just works, and it's not that way on the web. Yeah. The red the red squiggles

in Rust will make me pull my hair out, but they make your app work. Yeah.

Not to mention the fact that 1 password has to work on every single app ever. Like, 1 password was throwing a console error in Chrome, and, like like, people had pitchforks out for, like, a week while it was being fixed. And I'm sure there's a process to get that Deno. But, like, running code on everybody's website, you know, and you have to take into account. I would love to see, like, the I'm sure there's, like, a hacks Scott JS file for, like, common websites that just fix it. I remember, I had friends that used to work at Opera, and Opera had a major major part of their browser engine Wes just hacking, like, Bank of America to work with Opera, like, just fixing the web.

Yeah. There's I know, like, weeds we have a Linux app, and the Linux app requires a lot of love to to make sure, you know, you Scott all these different, like, desktop environments and, you know, you got Wayland, and Wayland's got all these little, you know, quirks that are still getting figured out. And so, like, Linux takes a lot of love. The browser the browser extension, obviously, you know, has a bunch of weird quirks. Like, that was one of the things that was hard for me, like, trying to take over the sync concept is it was like, you know, oh, we can rebuild it this way. And they're like, nah. You can't do that. And it was like, why? And they're like, well, because the browser can kill the service worker, like, whenever it wants.

And it was like, wait. What? And they're like, yeah. You really don't know, like, when that's gonna happen. And I was just, like, blown away. I was like, oh, so you have to basically always assume that this thing may or may not ever be running. It's like, yeah. Pretty much.

We just recorded a a show on the cache API, and Scott was saying, like, you you can't know that it's gonna be there. You can hope.

Yeah. Yeah. Yeah. Node is the best that you get with the Wes. I think in a lot of cases, It's just it's such a unique because, obviously, like, it it moves so fast, you know, whereas, like, operating systems, you know, where you're looking at, like, again, like, the Rust mechanics, so I'm making a binary for, you know, a Mac. Right? Like, it doesn't it doesn't change that fast Wes the code breaks, but the web can. You know? Like, the the browsers update all the time. There's always little things that can go wrong, and so it's just a whole other, like, universe working in something that's that, you know, dynamic and changing. I was working at a company couple companies ago where we would build something, and they had been this Wes people who had worked in software in, like, the eighties and, like, business side people. And they were doing this, and they were just like, why are we still working on this thing? Thing? It was like, well, the API changed. And, like, why are we using the new one? Like, we you don't really get a choice. Like, it's not like you can't just, like, build it and let it go. Like, they were like, oh, well, company we worked at, their stuff still works, and they haven't had developers in 30 years. It was like, well, yeah, it's written COBOL, and it's running on a computer they have to keep in a, you know, hermetically sealed box. Yeah. It gets just reboot it. Yeah. Exactly. If it ever turns off I've worked with company where it was like that too where they had an AWS instance, and it was like, the name was like, do not turn off there be dragons or something like that. And it was like they had some identity management thing that, like, you couldn't man. Terrifying. We have a couple of shows every year on, horror,

Terrifying. We have a couple of shows every year on, horror stories like that. Actually, you must know you have a syntax basketball in the in the background.

I do. Yeah. I actually the funny I almost sent 1 Wes, Wes, Sanity it to you. My horror story, actually, Scott, you were slightly involved.

So not in a bad way. I worked for this company. This was years years ago. It was, like, my first real dev job. And we it was a, like, ad agency, a marketing company. And, they took on this website. So we had a team of, like, 60 people in Vietnam, and they were awesome. They crushed it. Wes took on this project, and they made this really cool design. It was a WordPress site, but it had, like, these triangle cutouts on the sides that would be transparent through to the back. But it also was a template, so you had to make these templates where the triangles would match up when you, like, did a page builder type thing so they could build their own custom pages. So the CSS was wild.

And after we took on the project, they were like, oh, US citizens own. That's the only people that can work on this. We can't have foreign contractors.

And so we were like, oh, no. So there was literally 1 front end dev and me, the back end dev. And, it was like, oh, I don't know what we're gonna do. So I talked to my boss, like, day 2, and the front end dev was really more of, like, a designer. Like, she had a graphic design background. She's really incredible with design. But, like, the project structure was was a little tougher for her. Like, at the time, I think it was, like, Gulp. It was, like, 2017, maybe, but it was, like, Gulp and stuff. Like, she really know much about that stuff, so she was kinda just writing raw CSS.

And so I literally emailed Scott, and I was like, I was again, my entire exposure to development as a community was this podcast and Wes courses. That was all I had at that point. I didn't know a single other person in the world that did this. So I I literally, emailed Scott, and I was like, hey. This might be dumb. I don't even know. Like, you might be famous. This might be weird. Right? Like, don't know what's going on, but we have a project that kinda has, like, blank check. Like, could you come in and do this? You were super nice about it. You responded. You're like, hey, man. No worries at all. Like, I'm pretty busy right now. My buddy, Eric, can tackle this Deno problem. Oh, yeah. Did Eric end up doing that for you? He did. Yeah. I ended up working with him on a few different things, over time. And then I ran into him. I ran into him, I think, twice at the airport over the next couple of months, like, just all over the place. But, yeah, it Wes, like, sublime.

He's a wild man. He's everywhere. Wes Wes, this is Eric Sartorius who JS the digital Node we had on the show. He has currently moved to an island off of Portugal and is currently living there. I think he bought some land in Portugal.

Yeah. He the last time I talked to him, he's buying a house in Phoenix or something like that. And then He he did. Yes. And then he's living in Portugal. So Yeah. It was wild man. Crazy, though. He came in and crushed that project because we had to, like they also had a blog in HubSpot or something, and so we had to duplicate the same website design to HubSpot.

And so, like, we had to, like, figure out how to make those modules exist over there and do all the CSS, and Eric was a lifesaver. The 3 of us had to knock out this project in, like, 8 weeks or something, and it was huge. It was it was crazy. We were staying up till, like, midnight every night. It was it was wild. That that's glad to hear. If you wanna hear about Eric's,

his digital nomad trips where he's traveling everywhere, it's episode number 586.

We'll make sure we have a link for that in the show notes.

Yeah. He was he was telling me, like, wherever he moves somewhere, he just, like, buys exercise equipment, and that's his whole apartment. It's just like Yeah. Well, I have it I have 1 of his kettlebells

in my house because he JS like, I'm I'm moving. I cannot take a kettlebell with me to Germany or something. I was like, alright. I'll take your kettlebell.

Yep.

Oh, so That's so funny. Okay. Well, I think we're we're getting up kinda kinda tight here. So, is there anything that we did not cover that you wanted to make sure we hit on?

No. Not necessarily.

I think we pretty much covered kind of the gist of it.

Nice.

What about,

sick picks and shameless plugs? Did you come with a sick pick or shameless plug? Yes. So I have a very pertinent sick pick, which is the next mini 3 color.

I think it's called color selector or something like that or color finder. So it's this little Bluetooth device. You hook it up to your phone, and then it's got a camera on the backside. And you hold it up to any surface, and it'll give you all, like, the color codes and even, like, the brand names. Like, Sherwin Williams calls it this and blah blah blah. Woah. It's like our HOA just told us we have to repaint our house for, like, the 10 year paint or whatever. And so I literally just went outside and stuck this on every surface, made a whole map, and sent it over to the paint people, and they were like, no problem. Done.

And now my neighbors all have the same thing, apparently. So it's incredible. That's cool. You can map your whole house even. Like, it it'll let you store the colors you Scott with, like, names and sections and all the stuffs. Like, I have our whole house mapped out now, like office wall, office trim, everything. It's amazing.

That is so cool.

Can you, go to bm.westboss.com? Because one of my projects is I converted all the Benjamin Moore paint colors to CSS variables.

I know you named it b m dot that's so funny. Check out b m. I'm curious if you tap it on your screen, if it would it would actually match it close enough for you to If it's short. Pull out your phone. Oh, yeah. Screen would be tough, Wes. Yeah. Screen JS screens are always different.

Yeah. But, yeah, that is interesting. It's gonna look like the pixels or yeah.

Yeah. And my, monitor the my main monitor is actually really cheap one, so I would guess that it's not very color accurate. Oh, yeah. Yeah. I'll have to find that. I'll let you know then. I'll reach out to you and let you know if it works. Oh, oh, so cool. That because we have we have all the books from, Benjamin Moore, Sharon Williams.

What's the one from Restoration Hardware has his own paint company as well. So we have all the books you can just

page through, and it's I love looking at those. So many cool colors. I think we need to be way better about it because just especially this you like me. And so I live in Denver, and, like, the hail and stuff like that just, like, chips away paint and all this. So, like, our, like, front porch, we have, like, you know, poles where the walkways and stuff like that. There's so many little, like, scuffs and chips and stuff like that, so I need to, I think, just be better about paint in general, but this thing has has been a little lifesaver for sure just with even, like, textiles and stuff like that. Because, like, you can, you know, use it like, color wheels. So when we were trying to figure out we bought a couch and, had a bad experience because we thought it was gray, and it was definitely, like, a sage green. It was just, again, the way it looked on the website on our computer.

And so now we've been really careful about, like, alright. Let's check what actual color this is, and then we'll go check the other color. That way you're Scott, like you don't have to bring things with you, but also you don't have to, like, guess from home. Like, yeah. I feel like it's that gray, or is it lighter? Is it darker? Like, my wife and I will definitely have that conversation.

Man, this is a great housewarming gift. It's, like, $100,

I think. Yeah.

That's such a good housewarming gift. Imagine. Because you're gonna paint your whole house

anyway. Right. Oh. Andrew, this JS just like a something I had no idea existed, and I'm like I'm totally like, wow. This is amazing.

No idea this existed before this. Yeah. That's so cool. I was when we this was our 1st house. We had apartments our whole lives.

And, like, I for the most part, I grew up in apartment, stuff like that. So when Wes moved in here, it was like, oh my gosh. We can do so much. We can put a fireplace over there.

Like, I had all these ideas. I did nothing. But I did buy the thing to figure out the paint for when I do start doing all these things Yeah. Yeah. Eventually. Well, we gotta grab coffee sometime, Andrew, if you're around. Yeah. Definitely. I'm in well, I'm not gonna reveal my location on the podcast. We'll talk later.

Shameless plugs. Anything you would like to plug? I know. Idea for 5 plugs.

Yeah. Shameless plugs. I mean, like I said, use a password manager. That's probably my biggest one. I don't know how shameless that is since it's not necessarily I would obviously prefer people use 1 password, but, you know, definitely use 1. It's huge. I would the other one, I guess, maybe, this would be more of a sick pick, I suppose. There's a book, though, called Asynchronous Programming in Rust by Carl Fredrik Samson, and it's it's all the examples are in Rust, but it's really much more about, like, how async works down literally down to the electrical signals and it's amazing. It's it's huge. It's it's, really definitely made me feel like I, like, gained a whole another level in my my understanding of what's really going on, so that's probably another sick pick. But, yeah, shameless plug then. It's just 1 password. Use it. Cool. Check out the rest of Wes community for doing these types of these books online that are all using the same template. I don't know what that is, but it's a lot of them do. It's great.

Yep.

Yep. Word.

Cool. Thank you so much, Andrew. This has been awesome. It's been really eye opening, honestly. So Yeah. Really cool. Yeah. Wow. Yeah. Definitely. Thanks for having me on. For sure. You're welcome.

Alright. Peace.