From Tailnet to platform (Interview)

What's up friends? I'm off the grid this week on vacation with my family, Spring Break is here. I'm enjoying my life. And this week I have a show for you with the Chief Strategy Officer from tail skill.

His name is David Carney. We're talking about where tail skill is heading. T-S-I-D-P, T-S-Net, acronyms all over the place, multiple tail nets, aperture, their AI gateway, click list auth and so much more. Big thank you to our friends and partners over at Fly for getting our back.

They support the show. They make it happen. So thank you for that. Check them out fly.io.

That is the home of changelog.com if you didn't know. Learn more at fly.io. Okay, let's do this. Well friends, I'm here with my good friend Chris Kelly over at Augment code.

Chris, I'm a fan. I use Augie on the daily. It's one of my daily drivers. I use cloud code.

I use Augment. And I also use Antcode and others, but Augie, I keep going back to it. And here's where I'm at. I feel like not enough of our audience knows about Augment code, not enough about Augie, the CLI.

It's amazing. I love it. What can you share? Yeah, we often say Augment is the best coding assistant you've never heard of.

And that's both frustrating as to some that works there. And it's like very proud of the work we've done. But also like inspiring like we want to go and sort of punch above our weight, which is like we aren't anthropic and we aren't open AI. And so the quality of the product itself, you know, with our context engine, when should you do cush it, people are like just blown away by that.

And so like that keeps you going every day. So not the best lead here, but this is a paid spot. You are sponsoring this show to get this awareness. Now at the same time, we're selective and I love to use your tool.

But there is in the world. So a lot of developers look at the space and they say, okay, well, how long can this work? How long is this sustainable in the case of cursor or windsurf or you pick the name and you think this kind of tokens help me shape a lens for audience? I think it's a lot of awareness, right?

And like, cursor got a lot of publicity early on for like fast revenue growth, which well deserved. I think, you know, frankly, some of the media got that gets the story wrong and that like, if I gave you a dollar 50 for every dollar you sent me, I'd be the fastest growing startup in the in the Valley. And so when you're selling discounted tokens, yes, of course you're going to go very fast, but all that money plus more goes to the model providers. So I think the real story is the story of anthropic and, you know, being an API provider.

I think the market is just moved so fast and there's so many pieces of competition out there that it's just hard to get noticed. So friends, I love Amit Code and I love you Zun Augi. Yeah, I highly recommend you use it. I love you Zun Augi.

I can hand Augi a well-defined specification, a well-defined PEP as I call them in my world, an agent flow and it executes flawlessly. So the cool thing about Augi that I love most really is that context engine and I can hand it a task and it can just churn away on my well-defined plan and just never bother me and accomplish the mission. It is so cool leveraging the latest models, the context engine and all the fun things behind the scenes in that awesome CLI. So yes, go try it out, ogmentcode.com right in the top there is a CLI icon, a terminal icon, click that, install it, and change your world.

It's gonna be awesome. What friends we're here with, David Carney, co-founder, chief strategy officer of TLSK. Friends, you know, I'm a big fan of TLSK. So David, welcome to the show.

Yeah, thank you, I'm glad to be here. That's a big role. I mean, that would, that would shake me in my boots if I was Chief Strategy Officer of TLSK. What a, what a big platformer building and a lot of moving parts and a lot of direction you can go.

It is a big title and it's one of the clear. I'm not the, I'm still not the only one thinking about strategy at TLSK. I hope I'm moving parts. But being the top of it all, what does it take to, what does it take to lead strategy in some organization like TLSK?

Well, I wouldn't even say I'm leading like a holistic strategy. This stuff I'm working on in close partnership with my co-founder Avery, and a new VP product and other parts of the team. I'm focusing largely on, I guess, the strategy at the edge of tail scale, which is something that's sort of come about in the past year or so. So for the uninitiated then, describe tail scale from the non-edge, and then take me to the edge and what that means.

The simplest way to think about tail scale, and sometimes people ask me, like, well, what are you building? What do you do? And so explaining it to a lay person is very helpful. And so first and foremost, tail scale makes it possible to connect any two devices, anywhere in the world with strong guarantees of the identity of the user and the device at either end.

And if you can do that for any two devices, you can do it for an arbitrary number. So you can start adding one device, one user, one server, whatever at a time until you have basically what looks like a mesh network and it's completely private. Then you can layer on things like access controls, so you can be like, oh, only these people should be able to access these servers or devices. For instance, the engineers can only access production, the accountants can only access the finance servers, so on and so forth.

But fundamentally, what you can do is do it tail scale is great private networks. And so when we launched the product, I guess we launched maybe six and a half years ago now, it was pitched as a VPN alternative or zero trust kind of replacement. It does a lot more than what a VPN is, but at the heart of it, it's a connectivity platform that's a private network that's fully secure and sort of using a mesh overlay pattern. So that's the core of what tail scale is and it has been for a very long time, and we've been continuing to build and build and build on top of that.

There's this motion that's started in the past year or so where the, I guess the use cases for tail scale have gone from just internal within a company. So I'm using it to replace my VPN or using a taxist production or I'm using it to deploy infrastructure within my company. So people are starting to use tail scale to deploy infrastructure to their customers. So for instance, there's a couple of cloud provider startups that are using us in a way that they bring up a tail net is what we call it per customer.

And so they connect a bunch of like say bare metal GPUs with customer infrastructure, they send up one of these per customer and then they manage it. There's this ability to create multiple tail nets inside of your organization now. So people are starting to do that to build say like a staging tail net or a testing tail net or a production tail net, that kind of stuff. What I've been working more on over the past, I guess year now is building I guess applications and services on top of this platform.

So showing people like, oh, you can create a tail net, it has these very interesting primitives where identity and connectivity and security are baked in. Well, look how easy it is to build like applications on top of these tail nets and deploy them within a bit of private infrastructure. And that has gotten me, I guess more involved in things like agent workloads and that kind of stuff where you want really tight boundaries on who can do what with identity associated with all those actions and some kind of compliance trail and all that kind of fun stuff. This, this fringe, this edge, you call it the edge, I call it the fringe.

What are some of the things that you've thought of? Like, how did you go with either yourself or other folks on the team to sort of go into a room and think, okay, what is the true edge? What are the applications we can build on top of our own platform? I'm assuming that's how you've positioned this.

What are some of those things? I know we mentioned, you know, authentication is one of them, obviously. So you have your app, it's your project, you're recently launched. But what are some of the edges of that?

What are you thinking about? Well, the thing we started with earlier last year is that we revived a project, an internal project called TSIDP, which like a lot of things that we built a tail scale, we don't do a great job of telling the world about. TSIDP was in a community projects repo. We've done a bunch of work on it a year or two prior.

And for those of you who don't know what it is, and it's probably most of your listeners. That's me too. Yeah, so TSIDP, you can think of it as a reflection of your identity provider inside of your tail net. It's almost like a locally hosted version of your identity provider that's private to your network.

The way it works is that it leverages the fact that every connection and tail scale has your identity baked into it already. When you provision a tail net, you basically have to say, oh, I'm going to authenticate with a zero or G Suite or Octo or whatever. We don't have our own IDP. We just hook into all the ones that are commonly used out there.

Well, once we can start generating keys based on a handshake or an interaction with your external IDP, every connection has got your identity baked into it. And so if you're sitting inside of a tail net, you know everything that is connecting to you. And so you can actually build a small little application that just knows everything or knows the identity of everybody. And so with that, you can actually create effectively an OIDC provider.

So that's what TSIDP is. You can think of it as like a locally hosted private OIDC or an OAuth endpoint. And that allows you to do all sorts of neat little things. Like you can start plugging MCP clients and servers into it.

You can build all gateway patterns where if you need to do like token exchange or if you need to do dynamic client registration, you can basically do it with TSIDP. So you can keep all this interesting identity management stuff private here telling that not expose it to an external IDP. That's interesting. I mean, we've talked about OIDC recently with Nicholas Zakis around NPM security.

And that's one of the things that NPM required, you know, modern maintainers of this age to essentially have one blessed way to publish to NPM. And they had this issue with like rotating keys and that secure layer was largely brought on by OIDC. That was the first time I started to dip my toe into authentication nerd too deeply besides I like to authenticate with things. I like to have an identity when I go around.

I like my S and H keys like to be me where I need to be me. But I think I've been like hitting rocks together compared to maybe what even though I've been a tail skill user for so long, I feel like every day I learned something new about TLCL. So what does this help me understand what that enables them? What kind of applications does it mean?

So if if when I authenticate and I have a tail net that gives me a mesh network across whatever device I want to connect to, whether it's a home lab or enterprise or a prod or stage like you mentioned, what are some ways that enables a developer to not have to like shell out to somebody else's OIDC, but to be their own within their own tail net? What does that do? Yeah. So, for instance, I have a home lab.

I have a prox box server on it. Fantastic. And so when I first started using prox mocks, like, yeah, you know, I set it up on tail scale. I hit the internal IP on it.

So I could access it over my tail net wherever I was in the world. But I'd still have to log in with my credentials. There's a way to set up authentication with prox mocks that uses DSIDP so that it basically just automatically authenticates you just by virtue of the fact that you're on the tail net. It knows who you are.

So I don't have to type my username and password into a modal and hit submit. I basically just visit my prox mocks instance locally. And I'm in it. I'm a little bit close to now.

Yeah. So Alex, yeah, published a lot of videos on all the tail scale tech. He actually has a video on this. And I think an update for it, too, after we brought TSIDP up to the MCP spec last year, he refreshed his video on how to set up TSIDP to work with prox mocks.

But yeah, it's super convenient like that. At tail scale, we use it internally. For instance, we have it set up so that our revenue team, if they need to access Salesforce, they don't have to type a user name and password. They just can visit, they can just visit Salesforce.

Salesforce is configured basically to jump through our local TSIDP instance instead of having to do an all-flow. So this is like click this login essentially. This is just me. And I can just go around my do my business inside my business or in my home lab, which is kind of like a mini playground for most people and not have to even rely upon something like one password to put a password in your just you and you just go there and you just logged in.

How does that work? Yeah, I mean, you're already logged in. I guess that's the thing with tail scale. Like when you're on the tail, you've already done an all-flow.

And so why do it again is basically the question we asked. Right. Every connection can assert your identity. So we just leverage that.

So obviously, there's a bit of work you have to do safe with Proxmox or whatever to set it up and point it at TSIDP. You've got to set up TSIDP inside of your network. It's pretty straightforward. We're working on making that easier too.

But once it's set up, it's just like this magical experience where people just forget about the fact that they need to log in anymore. But under the covers or under the hood, it's all safe and secure. It's just like you're doing it all off-flow. It's just silent.

So if I had a Proxmox server or maybe a database server or an ink is on top of a Proxmox be it just anything like that where I have a network of other machines, what is the process to support TSIDP? Is that well published? Is that burgeoning? How mature is that for a developer to pick that up today and just start implementing that in their infrastructure?

Yeah. Well, it is. The code is open source. It's on our community projects page.

I think it's GitHub.com slash tail scale slash TSIDP now. If it does support, I believe a lot of 2.1 nowadays, we brought it up to speed, basically to keep pace with evolving MCP spec last year. So we added a bunch of other stuff to it. But people are using it.

A lot of home aders are already using it. We've got a bunch of what we call tail scale insiders that are using it too. Again, we just haven't talked about it enough. So I don't think enough people are using it or even aware of it.

But it's there. And it's open for contributions to people on an ad or an standard make more requests. Is it something that is just inherent of you using tail scale that just comes along with using tail scale and authenticate to it? Or is this the OIDC part of it does have to be a hosted server locally and run that you have to get against?

Yeah. You need to run it as an instance. I have it running in LxC on my Proxmox server for instance. It just starts on boot.

What's involved in that? Is that running on Ubuntu, pretty common, pretty easy, via system D? Can you want me to? Some of the details potentially there?

I think I'm using Alpine for it. It has to double check. But it's just a go binary. So what TSIDP is built on top of this other piece of tech we have called TSNet.

You can think of TSNet as a complete user space stack. Like tail scale stack. It's like a user space networking stack. Again, it's a go library.

So you can compile TSNet into existing go applications, for instance. And we've done a bit of work on bindings for other languages. But the go chain is the most by far for this. But what using TSNet lets you do is any go application we've compiled it in, you can have it show up.

So it looks like a node on your network. Just like any laptop or iPhone or whatever. So it just doesn't know gets its own IP address in the CgNet range, which we use internally. You can apply ACLs to it, policies, all that kind of stuff.

You can build applications with that. That's what app returns as well. It's fundamentally a TSNet application. So it just shows up as a service.

So the nice thing about TSNet is that you can turn any kind of service into effectively what appears to be a device. And then you can apply rules in terms of who can access that, with what level of permissions and all that kind of stuff. I feel like you're the most coolest, under known, crazy tech. Every time I peek behind the scenes, even further, I've talked to Alex Meetimes, he and our friends, Alex Kreschmore, our audience knows Alex, and obviously you do too.

But every time I go a little further and a little deeper into my networking nerd world, I just learn more about what I can do with tail scale. And it's so wild how, like I'm really, like when we're done with this, the first thing I'm going to do, it's a Wednesday, I'm hoping maybe by next week, I will get this spun up and I will not have to authenticate to my prox mocks. What does a, what does a tool like prox mocks or other services that one might run either in their enterprise infrastructure or in their home lab, which is kind of a snapshot version or a playground for most folks that might be not so much enterprise but team based or just running offs and infrastructure, like who isn't doing that these days? A lot of people are.

What does it take for a prox mocks to support that? Is that something that prox mocks has to do? And what are some of the protocols required to support this? In terms of just running like a TSP IDP as a service inside of your network?

Well, like how does how does prox mocks be able to support TSP? Oh, it's just another OIDC endpoint. Right. So there's there's a lot of support.

So all supports OIDC, then that's the that's the ticket in. Yeah. Or yeah, and we've added, I mean, there's OAuth 2.1 support or 2.0. I mean, we brought it up to the almost OAuth 2.1 as the MCP spec was evolving last year and then we paused it a little bit.

But yeah, OIDC, OAuth 2, it should just work. That's it. That seems pretty simple then. I've never met with this at all.

I'm going to miss this. It's a new world for me on that front there. Yeah. So this is the, yeah, I'll give you feedback.

Good. So this is an example of the edge. So you got TSIEP as long as you support OIDC or OAuth 2 or 2.1, then you can use this as an OIDC provider, which essentially is the effectiveness of signing with Google or signing with GitHub. Is that what I'm, is that what you're putting down?

Yeah. Yeah. It's like one of the reasons we we spent some time working on TSIEP last year is because a lot of the existing IDPs, like the big ones out there, didn't support some of the things that MCP was calling for like dynamic client registration, for instance. So what, so we built that into TSIEP.

So effectively let us bolt on these missing capabilities. So you can, you can not only continue to use your existing external identity provider, but you can augment its capabilities with TSIEP inside of your private network. Take me to that work. There's a lot of folks who are down with MCP and not down with MCP.

They say it's a fad. They say it's a stay. I think it's all about how the context when it gets impacted to the user. I think everything in this world is burgeoning in like what was, yesterday is not tomorrow.

What is, I mean, you've been sleeping this for probably 12 months or more, building aperture and this edge you're talking about. What's your stance on MCP from a implementation standpoint and leveraging it? I was getting deeper and deeper into MCP last summer and definitely into the fall going to a lot more conferences, talking with many more people. And it seemed like things were just getting bigger and bigger and crazier and crazier all the time.

It seemed like iterations of the spec were coming out. People were reinventing things or it got to the point where I think a lot of companies or organizations were like, you know, we're just not going to implement this right now because we're going to change again. It's too fraught. Yeah.

Yeah. And it got, yeah, I got very fraught. And we actually pulled back a little bit from it because I think in September, I could definitely feel this fatigue just creeping in. I was talking with more people and they sort of started pulling back from going to conferences related to it.

I think everybody was just getting tired of trying to keep up with the spec and the evolving landscape. I think Samuel Olson had this great quote, which is a lot of people were just adopting MCP for lack of their own AI roadmap. And so I think, we're starting along those lines. I forget the exact word, but I was paraphrasing it.

But I got that sense to a lot of people were sort of chasing this thing because I think they thought it was the right thing to chase for them to actually come up with an AI strategy. And it just got more and more complex for them. And I think a lot of people started pulling, like, pulling the shoots, pulling the cords and slowing down to regroup into the fall. And that's sort of how we thought too.

It's just like the more we sort of dug into it, the crazier things seem to get sort of like, you know what, we just need to take a step back and simplify our own thinking and focus on like a couple of problems that we want to solve as opposed to trying to chase all of them, which is what MCP felt like it was doing. Now, in my experience with these kinds of standards, there's usually like this explosion and then things coalesce something a lot more sane. I think that is going to happen with MCP. It's just going to take us more time than we thought.

Dig me further into the dynamic term that you mentioned, I get to write down with MCP. So it was calling for this feature set that wasn't there. And that's why I had to go that route. Dynamic Client Registration, DCR.

And I don't know all the technical details of this. So you'll have to forgive me on it. Don't go with the details initially about that, but what does it do? What does it enable for the MCPs?

Or why is it in the protocol? It basically lets things like MCP clients and servers wake up and register themselves against like an endpoint without requiring a lot of manual steps or human interaction. So it removes a lot of friction in terms of getting things like MCP deployed across an organization. And you needed to support that.

And that's why you went that route. Yeah, well, MCP was calling for it. Right. And so it was like, well, this is where the spec is going.

And there's other parts of 2.1. And even some experimental stuff. And if you are RFCs that people were referring to, dynamic client registration was definitely one that a lot of people were talking about. And we're like, look, we can build this.

Like it's not exactly rocket science. It would be hard for an existing item to provide or retrofit this in because being an identity provider is a horrendous amount of work. We don't, we, Tailscale doesn't want to be an IDP. We've known that from the day one.

But we can extend the functionality of existing ones. And DCR was pretty straightforward for us, largely because it's like, you know, the identity of things other work. So, you know, if you have this, if you have this trust and these assertions, you can make in terms of who is connecting to what then like client registration becomes a lot more straightforward that way. Is it the point of dynamic client registration to enable the MCP server to spin up whenever you launch it or initiate it or instantiate it to attach itself to the tail net?

Is that the point of this dynamic client registration? Or is it the individuals coming into the MCP, maybe through CLI or other agent workflows? I mean, in my limited experience with this again, it's been more about us allowing, you know what, I don't have a great answer for you on that one. That's okay.

I'm trying to pick it up with you because this is, you know, when you're in the land of burgeoning, right, you kind of have to navigate some seaweed and some tall grass and you got to get your hatchet on. You're like, you know what, I don't really know where I'm at right now. This is moving so fast. What is the point of this, this thing?

That's what I'm curious about because it seems like that might be the case. Like I see a lot of folks delivering a CLI and a MCP in one, you know, a lot of go applications are doing this or go see a lot are doing this where there's still deliver a CLI in MCP server in one single thing and you can launch it via the CLI, which is pretty easy. And I imagine you want that thing to authenticate with a tail net. Like you've also been a network, I want to have an identity.

Be the MCP server for XYZ server or service and that's who you are and you've got ACLs and identity attached to you. Yeah, and I mean, that's how we've been showing it off to people. It's like, oh, I'm going to, I'm going to create a server. I'm going to create a client.

I'm just going to have it automatically joined the network. I'm going to, you know, a big part of like, I got to tell scales, like you want to give these things identity, you want to pass them around, you don't want to have people to have to say make a manual or static configuration or this kind of thing. I should be able to spin up, you know, if I'm on a tail net, for instance, I should be able to set an MCP server, I should be able to launch it. I should be able to grant access to that to certain people.

I should be able to tell like my colleagues and maybe some agents that are in like a tail net somewhere like, Hey, you've got this new resource available, you can go access it safely and securely. That's why dynamic client registration is like super important for us in general. And I think it's why it's so important just to the MCP spec as well. Take me back into TS IDP.

You mentioned not wanting to be an IDP. These are acronyms, everybody. Okay. I think it's what does IDP stand for identity provider?

Something? What does that mean? Well, identity provider, it's, I mean, like G Suite Azure, Octa, there's a lot of them, like geek folk. Okay.

You know, a thing that, that, you know, third party service that you trust to assert the identity of other things, or yourself to other services, broadly speaking. So, you know, everybody logs into everybody, well, not everybody has a Gmail account, but everybody logs into services like they enter your username and password or, you know, configure like logging with SSO or, you know, like with Facebook or whatever, that's, these are all authentication flows. Something has to know who you are and be able to assert that to other things that people trust. That's basically the job of an IDP.

Here's where I'm going with this. And maybe this is just hypothesizing this edge that you're maybe navigating with you and your team that are thinking through these things. I'm thinking, like, if you don't want to be an IDP, that makes sense. But you want to enable folks to create their own IDP, which is TS IDP.

It's the thing I can use to build my own essentially, and I can sort of carry my own identity around with me that it seems like I can run my own instance in my home lab on my Pro-Concerto, but it could be me everywhere if I wanted to be. That's what it seems like I could be, or I can build my own thing on top of that. I feel like we're going into this world where maybe the next layer of a lot of folks stacks, whether it's internally in a home lab, whether it's a small team, but the next big thing to maybe a medium-sized team that's already got motion in place, and now agentic is thrown into this world and they're bolting on and rebuilding their platforms on top of essentially AI. I feel like this world is moving towards self-hosted.

And the reason why I mentioned this question is the idea for TS IDP to enable me to self-host my own identity provider. So I don't have to log in with Google or log in with GitHub or log in with whomever, because the thing I forget most is like, which one did I log in with? And now I've given you my stuff, and I got to trust you with my SSO, my single-sung on provider, all these acronyms in this world is just ludicrous, basically. But is that, am I picking up what you're putting on?

Is that the direction you're trying to think things? Kind of. So just to be clear, like you still need an external identity provider when you're using tail scale, and specifically if you use TS IDP, it leverages the fact that you've got an external thing that you trust, because that's what generates the identity, and that's what we use with encryption keys, so you can figure out, oh, this thing is connecting to me, I know who it is. And so, however you're using tail scale right now, you've got to, whenever you create that tail, that you're plugging it into whatever identity provider is out there that you currently use.

What I think is really magic about TS IDP is that it lets you not only manage identity privately and internally, so you can bring all of your internal apps, you don't need to configure them to go external. Let's just start thinking about your network as more of an extension of your identity, not just individual devices. And so you can actually start treating like a tail net as a collection of identities, or perhaps just one identity. And so it lets you, I guess, have a pocket of identity that's privately your own that you can start to do and manipulate and share things in the world with.

Now, there's a lot of, I think there's a lot of interesting ideas and maybe philosophy we can get into on this kind of stuff. And I thought to explore it, I know my co-founder Avery has a lot of this kind of stuff too, it's very, it's a very interesting and academic piece of tech. And this is, I guess, I can talk more about some of the journey last year if you want, but we started going to conferences and talking about TS IDP to people, especially in the eyespace because we're like, oh, this is very fascinating from an MCP point of view, that's you'd like, facilitates these views with them inside of a tail net, it helps you keep things private. And then it's the first class thing, TS IDP is showing that off and people are very interested in it, but then they come and come back to just more concrete problems.

So like, I need to get access to a customer network, or I'm dealing with API keys or like, much more tangible first order problems, whereas TS IDP is like three or four steps down the line with them, which is why we pivoted it last year, sort of a little bit away from it, but I guess in terms of projects, it's still very actively, there's a lot of active interest in using it internally, but it's not like, you know, it's shipped a little bit. Big thanks for friends at Nord-Layer for sponsoring this episode. So you, too, if a your GitHub org, you rotate your API keys, maybe you run to Pentabot on every repo or something like it, and then you onboard a contractor by sharing a VPN config over Slack and forget to revoke it for months after the contract ends. And that person still has a tunnel into your internal systems, maybe even right now, go check it, all this from a laptop, you don't control on a network, well, Nord-Layer is a network security platform built for businesses that actually operate the way modern teams do distributed remote first and moving fast.

It combines VPN access control and threat protection into a single platform based on zero trust. All the right people get access to the right resources under the right conditions, no implicit trust, no access lists, first it deploys in minutes not months, nor layer runs on Nord-Lanx, their VPN protocol is built on top of our guard and works across every platform, Mac OS, Windows, Linux, iOS, Android, no hardware to rack, no complex configs, you get granular control over who access is what, from where on which device and when that contractor's engagement ends, we know what revoke access from day one on one dashboard and it's done right then and there. So plans are eight bucks a month, you get 22% off Nord-Layer right now, yearly plans, plus an extra 10% off with coupon code, changelog-10-nord layer, try at risk free with a 14 day money back guarantee, check it out at norlayer.com slash the changelog again, norlayer.com slash the changelog. One of the things that are most active for you now, I think this might be one of them and given appatures announcement and that's sort of the underpinnings of all that, but what are some of the other things that are more active, even with API keys and those are being thrown around everywhere and it's kind of to some degree solved most of that and it's hard to tell everyone about the cool stuff you have and now you have a chance.

Yeah, and thank you for that. Yeah, so Aputure is definitely the evolution of a lot of that exploration last year and so for those of you who aren't aware, Aputure is basically an AI gateway built on top of TSNet, which I mentioned earlier that works inside of your tail net and you can expose it with our ways to expose it externally, but essentially it's a private AI gateway that lets you consolidate all of your API keys inside of it. It just looks like a node on your tail net like any other wood. After spending months and months going to various AI conferences and showing off DSIDP and just talking with all sorts of people like engineers, CISOs, people in IT, what have you, time and time again, people were saying things like, oh, TSIDP, super fascinating, interesting that you guys are working on all this kind of stuff, like I see the merits of tail scale, multi-tail net, which is the other thing we've been working on internally is super neat, but what I'm really struggling with is just trying to figure out how to manage API keys because they're all over the place.

I can't claw them back because it'll potentially disrupt production or some engineering workflow, trying to go really fast as a business. It's just dangerous, got API keys a lot of the place, people trade them, they get exfiltrated, they get checked in, and they have very large accounts or credit cards associated with them. It's very hard in some cases to track usage because a lot of API calls are inherently anonymous. We were sitting around at a company offsite back in November, just talking about all the things we've been learning over the past few months and we're like, well, wait a minute, if we built a gateway and we used TSNet for that, the gateway already knows exactly who you are because everything that connects to it over tail scale has identity baked in.

So if we put the API keys on the gateway, then you wouldn't need to share an API key with anybody inside of your company. You could just say, oh, if you have a coding agent, just point the coding agent to use the gateway instead. The gateway knows who you are. So then all the API accesses have identity associated with them.

All the API keys can be withdrawn. So you end up with a single point of observability control and access for your entire team. So because engineers get onboarded faster because they can just tell their peers, like, I'll just point your coding agent at the proxy, everything just works if you're on tail scale. That's a security team to say, great, we can get rid of all the API keys that are all over the place.

We can just tell people just go to HTTP for us, HTTP colon slash AI. And then every API call has your identity associated with it. So you can just log everything. And so we use aperture internally right now.

And I think we've got, I don't know how many tens of thousands of API calls across a big part of the company at this point. We've just got every interaction with all of our coding agents going through aperture right now internally. So we have full visibility into how people are using AI. All the requests, all the responses, the full logs, we're mining it for tool calls.

And our security team doesn't get a review if they need to. We're working with third party providers to start doing analysis of logs like in real time and sort of after the fact. Like, there's like all this like stuff that is unlocked for us. But initially, it's just started with like the simple idea of like, we just want to solve the API key problem.

And it's, I'm sort of meandering a little bit, but one of the reasons I love it so much is it builds so much on top of the fact that tail scale makes things so much easier because it takes identity and encryption that brings them way down into the stack like right at layer three. And if you do that, it simplifies, it simplifies so much stuff on top of it. And aperture is just an example of that. Anybody can take TSnet and build an application that looks like a node in a network and you get identity and connectivity and security baked in for free.

And that's just like, it's such a joy to work with it because as a developer for years, I spent so much time in heart, like just so many headaches about building authentication systems and managing, you know, managing infrastructure and opening up firewall ports and dealing with like, like, wait, listening IPs. And now with tail scale, you just don't need to do that. And then not at all. Yeah.

And with applications you build with TSnet, you don't need to do that. Right. So it's, yeah, it's just been a joy to work on this project over the past while. As a home lab, I'm thinking about having, is aperture available to anyone?

Is it a product? Do you have to pay for it? How do you deliver it to someone? It's, I mean, it's an early alpha.

Okay. Right now, there is, there's a self-serve flow. We launched it just, well, we quietly launched it a couple of weeks ago. Not quite now.

Yeah, yeah, yeah. We did a little, we did more of a push just the other day on it. Right. But if you go to aperture.talescale.com, you can sign up.

There's a bit of, like, we managed it as a wait list, just because we don't want the service to get overloaded. But the idea is that we're going to open it up like very quickly for everybody as soon as we're sure that things are just going to scale just fine. But basically, you know, we will provision an instance, you know, you authenticate it as a node into your network. It just shows up, you can start using it right away.

It's, you know, in line with what we already do for tail scale, like it's, you know, free for home app use. We're going to be announcing how we're bundling it and as part of the free plan, just, you know, free for home use, that kind of thing, just like we do. Obviously, you know, we're planning on it being a paid product for enterprise, but we're still exploring pricing and all that there. But yeah, but I want, you know, I want every home app, you know, anybody who's playing with LMs and API keys and stuff at home, they should just be using it.

It just makes things easier. Sort of like the, the tail scale way. Is this self-hosted then or is it not self-hosted? Because you said provision an instance?

Yeah, so we are, we are hosting these instances for customers right now. There is, there is plans and talk about self-hosted versions and certainly enterprises, like some of them would insist on that. There's varying degrees of what that might mean. If terms, like customers might be like, oh, I want to bring my own cloud.

You just write the logs there, but you can host the actual, you know, the stuff that's sticking up to CPU or so customers might want just like, no, we have to have everything on prem. But right now, we wanted to get opportunity as many hands as possible as quickly as possible. And the easiest way to do that and I think we wanted to say this way is frankly, it's just a lot of hosting instances at this point. Well, the reason I asked that question is one, I said earlier that I feel like the world is moving to self-hosted as a home labber.

I already felt that way years and years ago, but I feel that way more and more now because when the cost to produce an application that's bespoke to me goes to near zero except for my ability to specify it and my ability to describe intent, then everyone theoretically can be a builder in this new future we're going towards. And why not self-host a lot of things that I'm going to do? Because I'm already a home labber that makes a lot of sense. But I imagine a lot of teams, a lot of tech companies, a lot of non-tech companies, just like they're now tech companies, they think the same thing, they want sovereignty over their things.

They want to control their CPU costs. They want to trust the cloud less and still leverage cloud native type things, but in their own controlled way, especially when it comes to identity and especially when it comes to all tool calls and all responses, et cetera, because as an individual AI user, a team of one, basically, when it comes to the things I'm building, one of the things that I have anxiety about is, or just I suppose not anxiety, but I just wasted a record. It sounds like with Apatryr, I can gateway my way into all my AI and have my prompts and the responses stored there versus the compacting that happens and goes away and even have in-cloud code, for example, you have an export, we can export the conversation, basically. It's like, let me snapshot what we've talked about.

So worst case, I can walk with context of the conversation, maybe not context of what we actually, the underneath we described and it's a little bit explored. I feel like that, to me, I would want personally, maybe this is direct feedback, but as a homelabber, I would want to self-host that, especially because of how secure or exposed I might be with those. It's not self-hosting your email. I think today, you definitely don't do that, but I think in this case, it's such sensitive or could be sensitive information.

I personally would prefer to self-host it. I'm curious why, given that you largely haven't done a lot of infrastructure in the history of tail scale, you've pretty much been a pointer in a lot of cases and not a lot of infrastructure required to build what you've built. Why now? Why build out instances and hosting and responsibility?

Yeah, or liability. All the abilities, you know? Yeah. No, it's a very good question.

It's a very good question. It's a very, very good question. And I agree with you. I think a lot of people will want and will expect to self-host it.

And we do want to provide a path to that. It's just, I get that. It's early, and it's this little team of mine right now that built aperture over the past few months, it's cliche, but we're operating very much like a startup. And it's like, well, we just need to choose one path and go really fast on that path.

It's like, what's the quickest way we can get feedback from customers, get people experimenting with it, getting to the point where we actually have traction. Do we have product market fit? It's the fundamental question. Once you have more product market fit, then we can start branching out and figuring out where that takes us.

But this, and frankly, internally, I also wanted to experiment. I think there is a world, to your point, I think data sovereignty is extremely important to people. But so is speed. I think there's a lot to be said for motions where it's like, oh, no, we can tell us how it can help you provision instances.

Maybe we hook into other cloud providers, or maybe we get to the point where people could start sharing their infrastructure and compute with other people, and we can make it possible for people to create their own cloud providers or some kind of democratic cloud system using tail-scal infrastructure. But I wanted to experiment with the idea of what would it take or how much would customers resist a day? I just want to launch an instance of my network. Just make it easy for me.

Just give me one click, drop a note in. Because there are still the guarantees. We can't just simply start injecting nodes into customers' networks. People have to authenticate them in.

So there's a lot of guarantees that we already have in terms of our ability to just or the lack thereof to take over customers' networks. And I think a lot of customers just want the speed and convenience to try something out. So we made a decision. It's working really well so far.

I've been actually surprised with how many people have just been willing to say, yes, spin it up, add it to my network. At some point, we might want to have a conversation about self-hosting, but for the purposes of experimenting with it now, this is totally fine because we trust you guys. But yeah, it's really nice for us too. There's something else I'm just throwing on too with this self-hosted world especially in your history.

Just go with me here and think a lot of you don't mind. Put all your cars on the table, David. I've been thinking about this world of self-hosted like we just had a really good conversation with the founder of TlDraw. And one of the things that TlDraw basically does is sell an SDK.

So it's not even fully big software. It's the SDK to build on top of. It's the concentrate. You just add water, essentially, which is one kind of fasting idea.

Great business, a lot of upside, no infrastructure, high margins because there's no service to spin up. There's no attached to AWS or DCP or you pick your cloud and you're now competing with them at some point because you got software that you're putting up in the world as licensed software, whether it's truly MIT license open source or it's source available, open source code, not to blend the terms there, just to be clear about that. But you got this world where you have, I think we'll have a lot more people wanting to self-host and those people can still be customers. Have you all explored or have you even thought about yet if you went that route, how you can license it and still sell licenses of it, where you can provide essentially a source available version to the open source world that, hey, if you're in a home app environment like you do now, totally free.

This license applies to you. But if you're in production or you're in an enterprise or you're in this kind of business class, the source is available. Contributions are not necessarily what you're trying to achieve, but you don't have your code out there so you can see it. But then you're also saying, here's a license to you or here's a license per node.

You want to have an aperture instance in your stack, you want to have multiple, I don't see why you need multiple, maybe just one is fine, but you got maybe a per user license or a per node license. You tell me, I don't know how it actually permeates when into the network, but have you explored that world yet? Are you planning? Yeah, we're planning to.

We've definitely started talking about it. Even some of these bigger, we've had a lot of enterprises show up that are very interested in aperture and they've been bringing these things up with us as well. I think there's a world of possibilities for us there. I'm a big fan of open source in general, and I have a big kind of self-hosting things.

I like to play around with it. I like to be able to turn them off like I want to. You've got a home lab, David, of course. That's where we bake all our ideas first.

We take them, we do them in the home lab, we figure out how it works, we nerd out, we learn, we explore, and then we take it to where we're going. That's cool stuff. Yeah, exactly. I think with me is the bigger thing that just keeps me going as a founder.

I want everybody in the world to be using tail-scale because it's just a better way to do networking. Anything that's going to encourage that, I want to pursue it. I think, obviously, having a self-hosted version of aperture is one way that will enable that. Getting more people just to build TSNet applications is another way to do it.

Everything's on the table right now. For the purposes of it gets to speed and getting feedback and figuring out where we need to go next, this model that we have right now, I think is the best one because frankly, we're making updates and rolling it future so quickly that trying to manage those with self-hosted installations and working with database upgrades and security and everything behind them. We sort of did a bit of the math where we need to choose one path and keep it super simple and just manage things aggressively. It makes sense in this case, then, to cloud first, not because you're not for self-hosting because you need to maintain velocity.

The only way you can really maintain reliable velocity, in this case, is to have your own instances. But in the future, if someone says, hey, you know what, I love this, I'm down for it, except I want to self-host. Then when the product has proven itself, that makes more sense later on. That makes a lot of sense.

That's where I'd like to go with it for sure. It's easy to say that. It's easy for me to say, hey, just make this a self-hosted instance. It's easy to say those words, but then to actually support it is the challenge because then you have versions out there.

I suppose you do have database migrations, but if you know which version you're on, you can pin to a version and you do a good job with engineering and database migrations, then that can largely be collapsed to almost no pain. I get that it can be painful. Then you also have containers, Docker is certainly one of the things you can do that with. They've rolled out harden images.

I'm sure they would easily roll you into an aperture harden image that you can just go home. It's there. You're using the latest version of it kind of thing. There's a lot of things you can do to simplify it from a host standpoint or a self-host standpoint.

It doesn't have to be. Here's my code. It is a binary too. You say it's a go binary.

You're largely a go shop. Go binary is a system D or go binary plus container is pretty easy. It's designed to be portable like that. I'm excited about all the stuff you're mentioning.

It's definitely stuff we've talked about internally as well. The moment you offer, I'm going to try it no matter what, but I'm a self-hoster. In fact, we'll side note here. I want Alex to bring back self-hosts so bad because I feel like now is the time to bring back the podcast self-hosted.

I don't know if he's thinking about it. I know he's got a big job to do for you while there. Maybe he's too busy. Can't think about it, but I like the idea because there's so much happening there.

So, aperture is built on TSNet. You mentioned TSNet applications. What are some other things? Can I go build on TSNet?

If I'm a builder, what ideas can you give this world to say? You know what? We can't do it all. Here's some ideas.

Do you want people like me to build on TSNet or do you want the only application builder? The bigger arc here is, I think, tail scale can and should become a platform. I think every platform needs a few killer apps. It needs to sort of lead the way it needs to demonstrate to people.

Look, this is viable. This is why you should spend your time on this kind of thing because there's an ecosystem that you can plug into. And aperture is definitely one of those projects for us. If somebody else goes and takes an existing AI gateway and retrofits it on top of the tail scale, let's win-win.

As far as I'm concerned, more people are using tail scale. Customers are having better security. More people are just familiar with TSNet, which is fantastic. When you start thinking about tail scale in terms of, oh, I can create a private network and I can add things to it and start controlling access to it.

It's a very abstract model. There's a lot of different kinds of opportunities and problems that can help to solve. There's something that we started talking about more in the past 12 months. We have a blog post or two about that, which is the ability to create multiple independent tail nets instead of your order, your team or your home.

There's API only ones right now, which is basically for machine to machine use cases. There's not a strong notion of identity. There's ones that are more directly tied to user identity. We've got customers that have a staging tail net and a testing tail net.

I believe those tracks of development will converge at some point. There's already some incredible stuff you can do with multi-tail nets. That's one of the reasons I think things like aperture and TSNet are so fascinating. I could create a separate tail net and I can make sure that we say nothing can escape from that.

I can go off and do its thing and I can run coding agents in Yolo mode. I can have them connect to MCP servers and I have permissions that can fly around inside of the network and it's all nice and contained. You can use tail scale for that kind of thing. Those are the kinds of areas where I'm really excited for people to start experimenting with and bring up ideas.

I'm just like, oh, if tail scale did this for me or if it let me export this kind of thing or if it could transport this kind of policy or if it could connect to these different things that I could achieve X and I want to hear more of those ideas so that we can start building more stuff and more features at the edge so that people can start using tail scale boards as a platform. I'd love to explore the idea not so much in this podcast but something that's on my plate is network isolation. Spinning up an instance, let's just say I like an Inkus. Are you familiar with Inkus?

I say, I'm not. Canonical used to have LXD so you know that you've got LXC and I don't even use those. I'm not super versed. This is what I'm exploring and learning more about so I'm from my audience and be like, get yourself up to speed here.

Okay, I'll attempt to follow this here. Inkus is like system level containers. So versus Docker where it's a protocol, it runs on the system, it spins up instances and it is a go binary. It's built on go.

The person who invented it for Canonical Ubuntu's parent company, it was called LXD. I think they had a licensed snafu. I don't know what happened there but something happened licensing wise that made Canonical change the direction of it and remove it away from I believe it's linnoxcontainers.org. If I can recall, let me just check my notes here and check out that.

Yeah, linnoxcontainers.org which if you go there, you will see Inkus, you'll see Inkus OS, you'll see LXC which is something you use in Proxmox, Distro Builder which can do some cool stuff with like putting distributions but Inkus, I'm actually going to go to their home page so I don't actually jack up what they say. Inkus is a next generation system container, application container and virtual machine manager. So much like you can do a VM and you want to actually have control of the kernel or the container itself can be you're borrowing the OS level, the hosts level kernel where a VM you want to have your own kernel. So you can do both of those in easy exchange.

So they're unlike Proxmox, they're very much differentiated and actually largely abandoned from a CLI standpoint. They don't really have a good CLI in the Proxmox world. So if you want to spin up a new VM or a new LXC, you got to do a bunch of clicking inside the web UI. Whereas Inkus is got a really great CLI, you can script a lot of this stuff and the difference between a container and a VM from a scripting API CLI world is the same, like the same kind of commands but arbitrarily different whenever you spin them up.

Why am I telling you this? Okay, the reason I'm telling you this is like, I want to spin up different layers of Inkus or a different container of VM and I want them to be in an isolated state. I want that particular container to know nothing about anything else around it. As far as it's concerned, it's in the black space.

Like it's literally, there's no star around it. There's no asteroid, there's no planet, there's no moon, like it's just in a sea of abyss and all I could do is do internet traffic out, pull down updates, send traffic back, but to its peers, there is no peer. You could do that with typical networking, but it sounds like with a multi net or some telnet food that I just don't have yet that I'm still learning about. I might be able to jail one of those containers or VMs in ways I just weren't wasn't able to before.

So that's why I'm camping out is like this world of like network isolation, put that new instance, that new VM or new container into network jail essentially. Yeah, I mean, a lot of the stuff you can do with multi-tail nets, you can do with just modifying the policy file in a single telnet. If your rules are aggressive enough, for instance. But there's definitely, there's a lot of people that were like, no, I just want, I don't want to mess around with a complex policy file, StuRisky, or I'm dealing with multiple customers and my customers demand, complete guarantees and isolation between them.

I don't want to be managing somewhere. I accidentally add a star somewhere that all the customers can see each other, for instance. And so multi-tail net is definitely, it's, it facilitates that significantly. So a lot of it's just peace of mind like, Oh, no, I have this particular tail net is used exclusively for this.

It can't like, it's not like it can make a lateral, it can't move a lateral to a different tail net, like they're completely isolated from each other. So it gives a lot of people just peace of mind. And frankly, it's like a divide and conquer kind of problem. It's like, well, why I have like one big complex tail net when I can have two simple ones.

Or I have my own that I've authenticated with because you said you have to have an OIDC provider and I've got to authenticate with tail scale with one of those providers, Google Google could be, GitHub could be whomever I choose. And so that establishes my tail net. And then beneath me building on tail scale, I want to be able to have a whole separate tail net that is not, I guess, even tied to mine, but something I can talk to, but it's isolated. That's where I think you provide some networking that is just like dark arts, essentially.

Yeah, well, yeah, well, with the API only tellness, you basically when you create when you get, I mean, you get an OAuth client back. And then with that OAuth client, you can do things like ad knows, cradofks, provision stuff like within that particular tail net. So there is, it is so tied with like, as you might call the primary tail net, like it is associated with that. But you know, for all the purposes, it's a separate network.

Right. Well, for me to spin up another sub tail net, I have to have a tail net, which means I have to authenticate the tail scale, right? So I have to have the tail net to begin with to spawn sub tail nets that are basically blue, you know, they're just blue oceans that are by themselves. They don't have a clue whoever else is around them just, but I have to have tail scale and a tail net to create sub tail nets.

Yes, exactly. Yeah. Well, Francis episode is brought to you by our friends at Squarespace, the all the one website platform for building your online presence and running your business. Here's what we have learned over the years, the best developers out there know when to build and when to buy.

And you could hand roll a booking system, wire up stripe, build an invoicing workflow, stitch together email marketing, and honestly, you'd probably do a great job doing that. But that's weeks of your life spent on infrastructure that is an actual thing. Sometimes it's smart as movies, choosing the right tool so you can focus on the work that actually matters to you. That's Squarespace.

It's the all the platform that handles the business side of whatever you're building for yourself, for someone, for friend, whomever. And two things I think are worth noting. First, offering services if you're doing consulting, workshops, freelancing, mentoring, content, Squarespace brings scheduling invoicing online payments and email marketing together in one single place, one dashboard, you list your offerings, clients book and pay, and you skip the part where you are playing accounts receivable in your DMs. And it's a real business, it's a business workflow, not a pile of SaaS subscriptions that are kind of duct taped together.

Second, selling content. If you've got your course ideas, your video tutorial ideas, or deep or deep technical content, you've been meaning to package up Squarespace let you gate it behind a paywall, one-time fee or subscription, it's your call recurring revenue from expertise you've already built. That's a good trade. And the point isn't that you can't build this stuff, should you?

Maybe not. Okay, head to Squarespace.com slash changelove for a free trial. And when you're ready to launch, use our offer code, changelog to save 10% off your first purchase of a website or a domain that's squarespace.com slash changelog. And we use our link, of course, you're supporting the show and we love that.

Once again, squarespace.com slash changelog. We got there by talking about different applications you think can be built on top of TSnet. And I think where we may have dropped off, I've not given a good trail for, and I know the listeners maybe but in the top set, if we didn't do this, it's like, can you give me a couple ideas? Like if you can go and if you were at a, if you're in the hallway, I have a conference right now and you're just talking to some folks, you know what, here's a deal and build on your TSnet or TSnet application.

Here's a place you can go play. If an enterprise can't even, and they're like, you know, we're just leveraging our tail scale and our tail net in these ways, how, what are some problems they're coming to you with that you're like, we're not going to get to that for a while. These are things you should build. What problems are some of your largest customers just, you know, on your, that's what you're in a case about what's the loudest cry in the woods of, this is what I want to build on top of my TSnet.

One of the bigger issues that a lot of, especially larger companies that I've seen coming up more recently is they have a traditional network, traditional VPN. It's like one monolithic thing and they're trying to bring up MCP servers and they're trying to bring up MCP clients and they've got these notions of like, they basically are thinking like, oh, I've got now agents that are trying to operate inside of the network the same way humans used to, right? Except, well, I don't need to go on about the dangers of sort of letting an agent run a mock internal corporate network. It's, it's becoming, yeah, yeah, it's, it's becoming, obviously more and more an issue for like, especially bigger organizations that are, that have like traditionally dealt with security from like, I'm sort of a very centralized monolithic, um, as perspective.

So I think there's definitely been this push of just like, okay, how do we start, like a segmenting or isolating or subdividing our network? How do we start decentralizing it more so that we can enable these different teams and pockets of the company to work more independently with each other or within the, like within, sorry, working independently to solve like particular domain problems while still, I guess enabling the velocity and freedom of access to like required information. So I think, I think tail scale is actually a way that companies can do that. I think there's just lots of different approaches, but tail scale definitely makes it easy.

It's just like, okay, well instead of like one gigantic model with like network, like maybe you start building like one tail net per workload, for instance. And we've seen this kind of thing with people who are playing around with Kubernetes, right, and they have like customer internal tooling that they need to like some kind of internal monitoring system was like, oh, no, when we bring up a cluster, we've got these applications that need to sit inside of it, it has to sort of moderate or govern certain kinds of networking access. Like we do a bunch of like log analysis, maybe we do a bunch of real time stuff. Like how do we, how do we insert these applications that we've built into like these networks, you know, in an isolated way?

And so I think there's a lot of internal applications inside of companies that need to stay internal and private, it feels good for that kind of thing. You can retrofit them into inside of TS net, and then you can encapsulate sort of entire workloads inside of tail nets themselves. And it keeps, it helps people reason much more about like a safety and security that way. Where does someone gets more details about multi nets then?

Because this is what you tell? Yeah, we've, I mean, there's a couple of multi tail net. Yes, let me let me be on brand with that. Yeah.

Yeah. Yeah. I just want to multi net because everything else is something that is like multi net. I just try to follow your lead there, David.

No, no, it's good. In fact, I'm sure a product team will watch this video and maybe think more about the name we've been debating and internally about how to call these like what to call these things. There have been a couple of blog posts even over the past year. So even if you're to Google for like tail scale multi-tail net, you would find one.

It is, I believe in beta right now. I'd have to double check that. But it is accessible. Yeah.

Two home lab users. Yep. Sweet. Okay.

While you're doing that look up here, I'll fill some air with this. I think for the branding team remark, whoever's listening, our listeners is what I think the better name actually is multi tail net because you already say tail net. It would not make sense to like shorten that to multi net I messed up. And so I put my like branding head on thinking about how I would actually frame it my own mind if we're my product.

And I would call it a multi tail net because that's truly what it is. That's what makes the most estimate as well. So if that's what you're thinking, good job. Yeah, I just double check.

Yeah. So we, our marketing team did a great job with this fall update we had back in October and there's a blog post called one organization multiple tail nets. It talks about this over a page or two and then just how things are at least at the time of this blog post and in alpha program. But we've been steadily working on these features on the features related to multi tail nets over that time.

I'm super interested in this. I love to see where this goes because I think there's a lot of opportunity with subnets multi tail nets. You know, this problem that your customers are bringing to I can care with that because there's things that I'm doing inside my network that essentially is on my flat VLAN. You know, I got my traditional network that's across, you know, my 192 space and then I got my tail net, of course.

And there's things I want to isolate that I'm just not, you know, and I guess I'm just crossing my fingers because I'm moving out of velocity that doesn't let me slow down enough to be secure. And that's the job of tail skill I feel. That's where you know, that's why I use tail skills. That's why I keep investing more and more knowledge into what you are doing because you guys are like, does networking wizards and you love go?

I love go. If you're not going to be a gopher con this year, David, you all should reconsider that. Go for const the best place to be. Yeah, I just think this is super cool.

This idea of multi tail nets. I want to like dig into this between this and T S O I was it my gosh, so many I can tell me my notes here. Don't tell me their names. We need their names for these things.

It's okay, though. I mean, it is a T S IDP that doesn't make sense at a tail scale identity provider that totally makes sense. It's just so many acronyms in this world. It's hard to keep them all down the tip of my tongue.

So you got a lot to cover there. So those are two things I'm taking away from this for me personally on homework, because I don't want to log into my proximal anymore. I don't log into certain things I'm self hosting if everything I still post that has a login prompt. Even my true NAS box if I if my true NAS box can be O IDC compliant and let me use this T S IDP I'm on it.

Yeah, then that'd be great, you know, because I don't have to log in anymore. That'd be awesome. If I might then he could truly just follow me. And I think the challenge and I think for you all is it's a constant, I would say marketing battle, but I think it's like a you have so many homelabbers out there.

So many people probably playing with their stuff. You need more people just naturally sharing this stuff. And I know Alice has a great job of your YouTube channel. I mean, just tremendous job on that front there.

I think you're constantly having this problem. I don't envy your position at all with constantly having to update people. But there's just a sea of great stuff underneath tail scale from multi tail net to the things we just talked about. Those are things I'm walking away with.

You know, I do want to circle back to if you don't mind this idea of of aperture and really just this less about the product, but more about this idea of having an AI gateway. Help me understand why you feel so strongly about it. I imagine you do. I kind of have this feeling too is that I'm not sure if I'd apply it at my home.

I think maybe I would, but certainly in a burgeoning team, a small team, definitely a small business or an enterprise where you're sort of like mid small to medium size. But this idea of an AI gateway one for security, two for API keys and just like the concerns there. But even just me not having to have this anxiety of loss when it comes to transactions, I'm doing with a generative AI where I'm knee deep in a world where exploring it, you know, it's largely just pros. It's largely defining specifications, large and defining intent.

It's largely even learning about things, building two applications just to learn. Not so much to build something to ship it to the world, but to learn about even authentication, like when I go play with multi-tenants later on, I'm going to go build a two application and I'm going to work with an AI to do that. But it sounds like the gateway can help me have a transactional case tree. Help me understand that world of an AI gateway and what people can do with it.