unrelated, but what's the path of least resistance to expose a couple of localhost-bound services to the tailnet, ideally with each having own hostname entry as the browser sees it? they're not containerised, just plain old daemons.
This should work out of the box with Magic DNS (part of tailscale features). If machine A is named larrys-laptop and is running a service on :8080, then from sandras-laptop just navigate to http://larrys-laptop:8080 and it should work, provided both machines are on the same tailnet.
I'm not understanding how this supports Tailscale's initiatives and mission. That isn't to say this isn't a useful feature for a business, but it feels like a random grasp at "build something, anything, AI related." As a paying customer I'm concerned about the company's focus being blurred when there are 3.8k open issues on their Github repo and my company has been tracking some particular issues for years without pr…
This seems quite useful to me, especially for a larger org.
If your dev's are working on LLM features, they'll need access to the OpenAI APIs. So are you just gonna give all of them a key? the same key?
No idea how this is solved at the moment, so seems like a smart step
unrelated, but what's the path of least resistance to expose a couple of localhost-bound services to the tailnet, ideally with each having own hostname entry as the browser sees it? they're not containerised, just plain old daemons.
Tailscale services will do that. You can do the proxying with tailscale serve, services gives you the MagicDNS name and virtual IP address bound to it.
Not trying to diss or anything but a capable engineer could spin this up within their organization in a day or two. So I’m not sure how useful this is going to be to the average customer. Perhaps to the largest customers who have sophisticated security and compliance needs but even for them this would need to be very very competitively priced to be worthwhile (cheaper than the salary of 2 devs for a year).
The true moat of Tailscale is the core product. That can’t be easily replicated (still). Perhaps some product to simplify controlling what resources agents in the organization have access to and having 100% visibility + audatability for them will be way more useful.
I'm not understanding how this supports Tailscale's initiatives and mission. That isn't to say this isn't a useful feature for a business, but it feels like a random grasp at "build something, anything, AI related." As a paying customer I'm concerned about the company's focus being blurred when there are 3.8k open issues on their Github repo and my company has been tracking some particular issues for years without pr…
There's actually a mass acquisition game going on right now in this space. Companies want to use genAI, but don't necessarily want to hire people to run their own models in-house. It may not be obvious to startup-y employees, but keeping data in-house is huge for big companies. LLM traffic is a lot different from established traffic that firewalls have been built up for. You can't block data leaks as easily as shutting down access to google drive. When you can't trust all of your employees, genAI presents a lot of new attack vectors.
Not trying to diss or anything but a capable engineer could spin this up within their organization in a day or two. So I’m not sure how useful this is going to be to the average customer. Perhaps to the largest customers who have sophisticated security and compliance needs but even for them this would need to be very very competitively priced to be worthwhile (cheaper than the salary of 2 devs for a year). The true m…
I built a similar gateway for my own stack and thought it would be a quick project, but the complexity is hidden in the details. A basic proxy is simple enough, but getting accurate token counts for streaming responses turned out to be a huge pain since every provider handles chunks differently. You also end up spending a lot of time writing adapters to unify the schemas so your application logic stays clean. If you care about precise billing or logging, it is definitely not a two day build.
unrelated, but what's the path of least resistance to expose a couple of localhost-bound services to the tailnet, ideally with each having own hostname entry as the browser sees it? they're not containerised, just plain old daemons.
https://tailscale.com/kb/1552/tailscale-services Tailscale services will do that. You can do the proxying with tailscale serve, services gives you the MagicDNS name and virtual IP address bound to it.
I'm not understanding how this supports Tailscale's initiatives and mission. That isn't to say this isn't a useful feature for a business, but it feels like a random grasp at "build something, anything, AI related." As a paying customer I'm concerned about the company's focus being blurred when there are 3.8k open issues on their Github repo and my company has been tracking some particular issues for years without pr…
Corporate/enterprise networks have nightmarish setups for centralizing access to LLMs. This seems like an extremely natural direction for Tailscale; it is to LLM interfaces what Tailscale itself was to VPNs, a drastically simplified system that, by making policy legible, actually allows security teams to do the access control that was mostly aspirational under the status quo ante. Seems straightforward? I think if yo…
Yeah I think it's better to think of Tailscale as an access control company which is utilizing networks as the utility vector, not a network utility company that also has access controls.