Fwiw, I don't think vendor lock-in is a bad thing, but being open source doesn't mean there's no vendor-lock in. If a client builds their system on top of an open source technology, then switching away from that dependency would have a cost, even if that cost is engineering man-hours.

If tailscale does not work out of the box with netcat, and requires a custom additional dependency to work, it raises the question that tailscale will not work out of the box with other tools like tcpdump or stunnel and apache, and I will need to install other custom dependencies like taildump, tailtunned, tailapache.

When compared to other solutions that integrate without additional effort, installing vendor-specific dependency forks/clones means that there is an additional vendor lock-in.

> port forwarding is actually a half-decent idea

You make it sound like both options are equally valid, and as if port-forwarding were some esoteric technology. It's not, one is good, the other is bad.

5 years ago I had a similarly bland position, live and let live, I'd go to a client that was using a Ddns (zapto.org) for production loads serving thousands of customers. 5 Years later, I see them constantly facing SSL issues, and network issues, and even if they weren't it's still the wrong way to do things.

We have to stand for something, get an IP address, get a domain. If you don't have either of those, raise funds, get a budget, speak to people, you can't tech your way out of some things, I know we are hackers, but sometimes the solution is not hacking. Yes we should develop the power to do things even without approval from institutions and without collaboration from the central NIC, or the domain holder, etc... But we should refrain from using that power and actually integrate with domain holders, actually get IPv4/IPv6 blocks.

There's many reasons why you would use a ddns or similar tech, lack of budget, lack of main domain holder approval, lack of NIC approval, lack of ISP approval. In all cases, you are way better off by actually going the other way instead of using a ddns.

1- no budget: Get a budget, a domain is like 15$/yr. a 1024 IPv4 block leased from a NIC is like 600-2500$/year, so the cost of a Host or ISP is 0.6$ to 2.5$, maybe they charge you a margin and you end up paying 5$ to 50$/yr? If this is an issue, maybe your project should die, how much is your time worth? Fund your projects accordingly, or let them die. If this is someone elses project, they cannot afford you.

2- ISP: Call your ISP, if they can't help you access your router, or port forward or whatever, hang up, call again. If your solution is to use a ddns instead of picking up the phone, you have overtrained your hard tech skills and need to work on your soft skills. Speak to a human, you won't get very far if you never speak to humans. This is not a niche thing, we call it port-forwarding but it's how TCP and IP work in general, this is the stuff of the internet, if you can't do something as basic as that, you are never gonna make it, sorry.

3- Domain holder: If you work for a client, and they have a domain, but you don't know who holds it, or where the passwords are. Don't jump to a ddns or buying another domain, integrate, investigate, do an inventory. At the very least buy another domain, a ddns is just cheap to the point of being unprofessional, see 1.

There's a 4th excuse that I'll handle as well:

4- I'm just testing, this is just a throwaway project: Even if it is, you are still underfunding your bets if you don't even have a domain and standalone non-firewalled IP, even if reusing an existing domain and host, we are talking about like 5$ per month. Imagine a professional of any class that cannot afford a tool worth 5$, even a plumber has a toolkit with a screwdriver in it.

Even if you share a link to your project to a friend, if it says hsabhsabdsa.tailscale.net or bjsdbsajdbsa.vercel.app , you are already neutering your project. You can skip this 'phase', it's not necessary for a project to go through all phases, especially if a vendor is trying to convinve you that you should go through this phase, skip it, tell them no, build it right even for your day 1 demo, it's better than having a pre-day 1 demo that has low quality and does things wrong.