https://geysermc.org/

They can! They just need a real computer, the real Minecraft game (Java), and then they can! it's so easy when you don't play the shitty mobile clone.

https://github.com/n0-computer/pigeons offers the same but with SSH. I use it in my homelab extensivelly for access, tunneling smb, postgres and some other minor bits.

How do you guys deal with nix & go cache? i hate when nix cold starts builds, tests without go cache.

I was just wondering yesterday if it'd be possible to have a tailscale client, or multiple tailscale clients in their own network namespaces, that could connect to multiple networks.

The slightly tricky part would be managing a local NAT that blends the two networks, and also does MagicDNS to answer on those NATed IPs. If routes conflicted, I guess you'd have to pick one?

Seems very doable though.

Not a huge lift to stick a PAKE in this protocol, though I'm dubious that it'd be much of a win. The PAKE + nameplate system in Wormhole makes a lot of sense, because you're doing one very specific thing with that system (moving a file from point A to point B). Here you're booting up servers; you're almost always going to have a non-voice channel to set up with.

> This is also why it needs PAKE as opposed to the simpler cryptography used in tailcat

May be my idea of simpler cryptography is incorrect, but PAKEs like CPace do seem simpler than public key primitives in Noise.

Is NAT traversal actually that big of a feature? The category of people that would use a tool like this already knows many ways to do it without NAT getting in the way.

(Author here)

WireGuard doesn't do NAT traversal. That's the main thing this adds. And this also adds a CLI tool + library to do streams over WireGuard w/o installing kernel routings, requiring root, etc.

IPSec may be a pain... but WireGuard is as simple as it gets in my opinion. Yeah, you may need to know basic IP concepts, like MTU...

NAT traversal is a different topic, WG won't help in that, and that can actually be a pain. I guess we should be using IPv6 already, and this tool would be largely redundant already. (not completely, encrypted access to isolated networks is a valid use case)

> it's a pain in the ass to configure it

Public/private key pairs are hard? It's no more terrible than other projects that require configs.

> pain in the ass to configure it

Idk? I found it pretty easy to configure by blindly following the tutorials and copy-pasting keys. The only footgun is the keepalive setting, which will screw up the tunnel if one end is behind NAT, that tripped me hard, but besides this, no issues at all.

always have! our darwin and windows clients are closed source, but they wrap the oss implementation in github.com/tailscale/tailscale and you can see and even use all the same hooks yourself.

the control plane is closed source, but headscale is an open source alternative that we embrace and encourage people to use if it meets their needs/desires

Oh, wow. I had no idea. I've gotten a ton of use out of memcached over the years. Thanks for all your efforts, Brad!

I wish his perkeep project was mature and stable.

It's an official tailscale product no?

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.

It's a pattern that occurs in commercial software yes, but Open Source has its own version of building mirror ecosystems. Collaborating to bleeding edge issues on robust infrastructure is very hard, so junior engineers that want to collaborate in open source (often for reputation building) can do so in these mirror ecosystems, it's an added bonus if they believe that they are contributing to the bleeding edge instead of rebuilding an enantiomer tech stack.

> if port forwarding works for you

> 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.