[Tailscale CEO here] I see a lot of comments asking why Tailscale would branch away from our "core product" and build this thing that seems unrelated at first. One answer is that just about every single Tailscale customer (or homelab user!) is dipping their toes into AI right now, and they often come to us and ask how to integrate their stuff into Tailscale. Aperture is our answer to that.

A separate goal I have personally: demonstrate that anyone can build really neat stuff directly on top of the "Tailscale platform." One of my rules for the Aperture team was, you're not allowed to change core Tailscale, you have to build entirely on top as if you were some partner company. So this is a demo of how anybody can make pretty slick, easy-to-use, and yet highly secure stuff by building on Tailscale (the open source packages, or the commercial product, or both).

(I'm a Tailscale employee) The recent versions of the Tailscale k8s operator actually used a pre-release of the Services feature to do exactly that. So, not much difference. The official Services release is making that functionality available for more use cases (and generally better documented and user friendly).

You’re right except in the very specific case of the App Store purchase or download process. You only get one chance at FaceID and then it demands a password. But, if you cancel and do it again, you get another chance at FaceID. It’s mystifying why they’d make that UX choice.

(Tailscale cofounder here) Tailscale already gives every node on every tailnet a globally unique internal IPv6 address, that is reachable even if you don't have IPv6 on the "outside" network. If your apps and OSes are all willing to use IPv6, you haven't had a problem since the early days of Tailscale; they've been solved for years.

Alas, the "apps and OSes are all willing to use IPv6" problem is a persistent one, so we have to make IPv4 work too.

It’s possible to build a cache without any insight, but to make a cache that works well in a given domain requires knowledge from outside the world of caching itself. The same is true of summarization and compression.

Tailscale now supports custom OIDC providers. But if you already have the ability to host one, you won’t benefit from what’s in the above article (which is about hosting stuff at home even without a public IP address). https://tailscale.com/blog/custom-oidc/

I recommend against using Funnel for this use case (because it exposes your server to everyone in the world, not just your trusted users). Tailscale node sharing is free and secure for private networks of friends, and there are lots of people using it with Minecraft: https://tailscale.com/kb/1084/sharing/

To answer the question in another thread, node sharing also works with UDP. (Funnel is TCP-only due to the vagaries of IP addresses and TLS certificates when facing the outside world, sigh.)

(Interviewee here) WireGuard itself barely touches DNS, and tailscale as far as I know doesn’t have any code that would change how your external DNS resolution works. What you’re seeing might be a misdiagnosis. If you email tailscale support we’ll be happy to help figure out what happened and if it’s a bug.

Exit nodes are usually still behind your firewall and have no open incoming ports. If you're willing to reconfigure your firewall to open incoming ports, you probably didn’t need Funnel in the first place.

In general, the load generated by a series of these pings is so low as not to matter, unless a whole ton of people start doing it at once. But in that case, gfblip's trivial backend code will ask the frontends to slow down so that aggregate load stays low.