Please be aware that when you use tailscale funnel you announce to the whole world that your service exists (through certificate transparency), and you will get scanned immediately. If you don't believe me just put up a simple http server and watch the scanning request come in within seconds of running `tailscale funnel`.
Do not expose anything without authentication.
And absolutely do not expose a folder with something like `python -m http.server -b 0.0.0.0 8080` if you have .git in it, someone will help themselves to it immediately.
If you are aware of this, funnel works fine and is not insecure.
Tailscale IMHO failing in educating people about this danger. They do mention in on the docs, but I think it should be a big red warning when you start it, because people clearly does not realise this.
I took a quick look a while ago and watching just part of the CT firehose, I found 35 .git folders in 30 minutes.
No idea if there was anything sensitive I just did a HEAD check against `.git/index` if I recall.
Out of curiosity, why? I use TS for all my homelab bits (including my HA instance), but connect to TS before opening the HA app. Is it just a case of making it easier/ possible to connect if you’re on another VPN? Are you not concerned with having something from your local network open to the internet?
After a decade with KeePass, I’ve finally moved to Vaultwarden. I’ll admit, self-hosting such a critical service still feels a bit scary, but the seamless syncing across all my devices is a huge upgrade. To balance the risk, I keep it tucked safely behind Tailscale for that extra peace of mind.
Do you have anything that’ll trigger a notification if there’s suspicious traffic on your local network? I may be overly paranoid about exposing things on my local network to the internet.
Besides the use cases listed, we see this as an opportunity for homelabers and organizations to add authentication with access control to already exposed services.
We are developing a similar feature and is scheduled to be available really soon. We've discussed some details in our public slack. Any feedback there will be helpful.
They switched me to CGNAT in my last speed upgrade, but I wrote to them about it and they moved me to native v4 straight away.
Their service is good on a technical level but they have the most aggressive and obnoxious sales reps. They scammed me twice with open lies on the phone (probably abusing also the fact that german is not my mother tongue) and had to fight for ages with their customer service later to get the issue resolved.
If you wanna go with them, buy on their website and hang up if anyone from 1und1 ever calls. They are official 1und1 reps and they will prove it you yet behave like scammers.
I can tell you that Deutsche Telekom has much much more aggressive sales reps than 1&1. (I've been with GMX/1&1 for ~15 years and with DT for ~2 years).
DT called me on phone over and over again, so much that I had to block them on my FritzBox. Several times they even knocked at my door.
Here in NL I've been able to replace router (Zyxel in my case) and ONT (Huawei in my case) with one SFP+ (went with some South-Korean one). Only had to register the serial of my SFP+.
ACES 1.x was quite old and released at a time where HDR displays were pretty much non-existent. ACES 2.x is not perfect but trying to provide display rendering transforms that hit contradictory requirements is really hard, e.g., need to have a really nice rolloff and desaturation towards white whilst being able to reach corners of the gamut.
Is this the first blender release where you can change the working color space? I thought that you could in previous versions but it caused issues with some nodes.
Now I want to look into it more, but I'd imagine that "Blackbody" and sky generation nodes might still assume a linear sRGB working space.
> Now I want to look into it more, but I'd imagine that "Blackbody" and sky generation nodes might still assume a linear sRGB working space.
Since people are always asking for “real world examples”, I have to point out this is a great place to use an agent like Claude Code or Codex. Clone the source, have your coding assistant run its /init routine to survey the codebase and get a lay of the land, then turn “thinking” to max and ask it “Do the Blackbody attribute for volumes and the sky generation nodes still expect to be working in linear sRGB? Or do they take advantage of the new ACES 2.0 support? Analyze the codebase, give examples and cite lines of code to support your conclusions.”
The best part: I’m probably wrong to assert that linear sRGB and ACES 2.0 are some sort of binary, but that’s exactly the kind of knowledge a good coding agent will have, and it will likely fold an explanation of the proper mental model into its response.
Display P3 (distinct from cinema display P3, because names are hard ig) is used as a render target color space. ACES (and its internal color spaces) are designed as working spaces.
If you make a color space for a display, the intent is that you can (eventually) get a display which can display all those colors. However, given the shape of the human color gamut, you can't choose three color primaries which form a triangle which precisely contain the human color gamut. With a display color space, you want to pick primaries which live inside the gamut; else you'd be wasting your display on colors that people can't see. For a working space, you want to pick primaries which contain the entire human color gamut, including some colors people can't see (since it can be helpful when rendering to avoid clipping).
Beyond that, ACES isn't just one color space; it's several. ACEScg, for example, uses a linear transfer function, and is useful for rendering applications. A colorist would likely transform ACEScg colors into ACEScc (or something of that ilk) so that the response curves of their coloring tools are closer to what they're used it (i.e. they have a logarithmic response similar to old-fashioned analogue telecine machines).
Yeah, like, let’s say that in your compositing workflow you increase exposure then decrease brightness. If your working color space is too small, your highlights will clip when you increase exposure, then all land flat at the same level when you decrease brightness. If your working space is bigger than the gamut people can see, but your last step is to tone map into Display P3, you’ll appreciate the non-clipped highlights, even if your eyes could never comprehend what they looked like in the post-exposure-boost-pre-brightness-drop phase of the pipeline.
The key point is that your ray tracing color space and your display color space don't need to be the same thing. Even if your monitor only displays SRGB colors, it still can be useful to have more pure primaries in your rendering system.
> or you are saying if there is some intermediate transform that makes color go beyond P3 it will get clipped?
Exactly! The conversion between ACES (or any working color space) and the display color space benefits from manual tweaking to preserve artistic intent.
