- I was able to get my partner onto the tailnet by telling her to install an app and login. She doesn't know or care what wireguard is, but she can now access some of my self hosted services on her phone.

- I'm able to easily dynamically register machines to the tailnet, such as CI jobs

- I'm able to self host a DNS resolver and have it just work for devices connected to the tailnet

I'm sure I could achieve these goals with plain wireguard, but I feel like I was able to outsource significant complexity to tailscale instead.

Eg: is there a clean way to dual license such that hobbyist, and exploratory work (eg: a proof of concept done in a commercial setting) are allowed, but using it in production requires a fee?

If you've done this, has it been successful? Obviously there's been many projects relicense over recent years (terraform, redis, etc) - but it's less clear to me if this is a viable path for new projects starting out, or if it just kills adoption from the beginning.

I like the idea of dynamic tool/skill sets, but wonder if it needs to be part of the new session workflow where you would choose a group to activate rather than this dynamic.

I probably won't allow everything through it (eg: postgres, clickhouse etc can stay on tailscale), but I've been stumbling into use cases where I want to share things with friends or colleagues, and I don't want to put them on my tailnet.

Everything is version pinned and a deliberate choice to change, and a git revert away from changing back.

TBF the models may change underneath me to some extent still, but the cost benefit of running them myself doesn't pan out yet (for agentic coding at least, don't have enough local vram to get a usable context window and generation speed, self hosting on runpod or similar isn't economically sensible for my current consumption though I have tinkered with it)

To use a ridiculous extreme you can't breach a web app that isn't exposed to the internet, but the users can't access it either.

If you can connect/balance those goals to other metrics around cost and productivity, usability, and a realistic threat model, as guardrails then you incentatize cross-team collaboration to achieve the shared org outcomes.

As a developer, I quite like monorepos to a certain size (eg: until they get big enough that the tooling we typically use outside of big tech starts to fall down).

As an AI, I'm not sure that I care? I'd guess that context management can actually be easier if each microservice has a well documented API (openapi/graphql/grpc/asyncapi/whatever) and you provide the agent harness the ability to drop into each polyrepo as required (and give it the ability to access said documentation).

The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent.

Admittedly the way I'm using agents at the moment is more repo orientated where it's sandboxed to a single repo, but conceptually I think polyrepo microservices could end up being a sweet spot.

I guess you don't want to stop more times than needed, so maybe you'd want to cluster the demand somehow into "virtual stops", and you may lack some amenities like shelters.. so maybe the traditional bus route is good enough. Though it feels like it's ripe for optimisation (you know the classic no buses come for 30min then 3 arrive at once, or these buses are all full whilst others are roaming empty)

I'd love to see legislation that mandated a functioning web experience for critical services like this (banking, utilities, etc) - otherwise it will continue to further entrench the current duopoly.

(I suppose this is also an instance where I should do a better job of voting with my feet and supporting services that do offer this)

Eg: JDK + maven + junit + tomcat

Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc)

The people in leadership positions should be active participants, and not all decisions will be ones they are are able to make locally - but they should feel comfortable to present a POV and recommendation/tradeoffs upwards when that's the case. If the buck stops with them then they should be aware that "do nothing" is a decision that they are making.

Spoiler: neither the commodity solution or the in-house solution will ever be perfect, and you should be really self critical of whether you're building something in-house to scratch your own itch.

If you can find a commodity solution with the right extension points that's often the best solution, failing that many times it's worth accepting the limitations, rarely it's worth investing in the totally bespoke thing (outside of your core domain/proposition).

My first thought was I hope they didn't make this mistake for everyone, and second thought how do I safely return this.

(Turns out it was a one off mistake, and returning the excess was pretty straightforward though probably the largest bank transfer I've ever made)

It also forces you to use DNS challenges, which means you don't require the publicly route able address.

Personally what I do is: - Predominantly use wildcards

- Run a tiny coredns instance with my A records for a internal subdomain of my normal domain

- Configure tailscale to use the coredns resolver

- Run two haproxy instances, one for internal services, one for public facing. The public facing one can't route directly to the internal services.

When even the obscure DNS provider I'm using is supported for DNS challenges, I really don't see much upside to using HTTP challenges anymore

It's the steam version, but Crusader Kings also hangs for a bit if you block it's network access