I do not have the luck to get access to computer in my childhood. But the articles still make me feel nostalgia, especially the sound. With limited resource, people at that times just create some good stuffs.

Oh no, I am just adding codex integration to my app with in-app tailscale networking, communicating with codex app server via websocket over tailscale

But I will still consider to release it anyways

250k for openwrt based risc v router? Maybe need do more work such as using vyos + fdio/vpp

This is cool, let aside the token usage, perhaps it can help analyze tcp throughput by redirect wire shark/to dump result

Opus 4.6 is already very good at troubleshooting all kinds of network problems if it has access to the command line tshark tool and the pcap files.

Agreed it’s pretty pro at deciphering logs, it figured out some weird NAT thing for me.

Finally a tailscale rust port is coming, i think it's will make build app with builtin tailscale connectivity more easily compared to libtailscale

I'm completely new to this space, but how are applications using tailscale as a library?

Are they creating their own mesh networks for internal or user use?

Imagine something like writing a server with an /metrics HTTP endpoint that Prometheus can then scrape -- but you bind it on separate port only inside a tailnet, with an ephemeral tailnet key and name it "metrics-service-blahblah".

Now you can simply write a script that uses the tailscale API to find all "metrics-service-*" nodes in your tailnet, and then adds their IP/DNS to your prometheus scraping list. Run it every 60 seconds. Done, now you can just deploy your app anywhere on any cloud and it will get scraped and that route will never be exposed to the outer internet.

This will basically just let you attach bespoke applications and not just "computers" to your network. I suspect I will get a lot of use from it.

Tailscale and Wireguard are great. I'm an OpenZiti maintainer and I've written/spoken about application embedded zero trust for many, many years. Still it seems most devs don't think it's important for whatever reason... It'll make me happy if Tailscale is successful here and can spread the word out to get more devs interested in embedding the secure connectivity directly into the apps instead of relying on the classic underlay network and bolting on security. If that sort of thing interests you, you could check out OpenZiti. It's not Wireguard-based for better or for worse you can decide (if you do end up checking it out)

Just speculating, but that it's an option to open/listen to a port, but that port is on a Tailscale network. So the app is largely unaware of the encryption over the top. Similarly, you could do similar for a client app. Where the Tailscale connectivity options are inside the app, instead of a proxy to the app that lives outside the apps.

Likely more transparent than explicit/implicit TLS.

As a developer who have been built some tailscale-based clients, I think this maybe acceptable because they running a business with money from the VCs.

And I am also very grateful that tailscale implement some workaround for systems such as apple-based OS with core APIs built into the open source code, thus if you really need you can just look the open source code and doing accordingly, though it really need some research work.

For the long term if they really do not want to open source the core client code (which I do not believe at the moment), I think support a fully open source coordinator and open source client based on the fork will still be doable.

Have built a cross alternative tailscale gui client based on tauri, the rust and ffi to cgo tailscale feel a little tough, I was wondering it will save a lot time to me if the tauri had been written in go.

Seems Miguel’s velox point a new idea, leveraging the wry and use ffi to go, and rewrite some tooling.

I hope I will have the spare time and energy to give a try…

Just in case you missed it and are interested in a go alternative https://wails.io/

just did some spec reading, it's quite clear and nit.

I can understand that put UDP payload into a single HTTP stream, at least when QUIC transport is in use, there is no UDP in TCP case.

The Source Address/Port in the UDP payload message serve as key to handle to the tunnel client if I understand correctly?

It’s great for you to open source the protocol and implementation, it written in rust which I will definitely consider to learn it add add to my vpn client in the future

After reading the article, I am wondering is that is there no test case to coverage the behavior that modify the CNAME order in the response? I think it should be simple to run a fleet of various OS/DNS client combinations to test the behavior.

And I also being shocked that Cisco Switch goes to reboot loop with this DNS order issue.