Will Norris

okay, it's back up. Immediate fire extinguished, but I'll be continuing to work on removing the reliance on maven.twttr.com and to just get this (and others) published into maven central.

Filed an issue with Hadoop project to track discussion of publishing on maven central with the current groupId: https://issues.apache.org/jira/browse/HADOOP-18223

The general response from the Hadoop project was that this shouldn't be published in Maven Central with the current artifact ID in the com.hadoop namespace. We had begun the work...

Actually, now that I think more about it... I believe maven.twttr.com was likely only running in the SMF1 data center in Sacramento (that's where a lot of internal tools ran)....

rather than add more magic env variables, I'd rather actually use caddy's configuration support. You can add configuration options for transports like anything else (see for example the [http transport](https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#the-http-transport))....

I definitely want to pivot to using caddy configuration for any future options like this. I kinda wish I had done it for auth keys as well, but that's already...

I **think** the recent config code changes may have fixed this. At least, my [current sample here](https://github.com/tailscale/caddy-tailscale/blob/will/examples/examples/proxyauth.caddyfile#L31-L38) is working well for me. Could you test again with the latest changes...

I've started using this with my custom caddy build for my personal website and am seeing the same thing. The caddy tailscale nodes are marked ephemeral, but are not getting...

Several questions... - do we know if the order of tags is stable and/or predictable? - are tags the right thing to use as the identify of the machine? Given...

> what if we only allow nodes with a single tag to be used with this? Well that definitely solves the tag sorting/ordering question. This still feels [round-peg-square-hole](https://www.youtube.com/watch?v=Nz8ssH7LiB0) enough that...