Thank you for the feedback. I had a lot of fun playing with the model (and still have some improvements on my mind that might require porting it outside of Shadertoy)

Is there any part that was especially hard to understand ? I'm trying to make it as clear as possible for developers without a scientific background.

This is an old post, but I've only recently (I'd say a few months ago) started to see Google's indexing bots pop-up in my instance's server logs, so this may be about to change

I don't use nginx-proxy-manager, but if you want to share what you tried, I will try to help you figure what's not working

Or you can quite easily configure nginx as your personal caching proxy with an arbitrarily long TTL/retention duration (you can check out my follow-up post for instructions on doing that)

I don't use Traefik myself, but this documentation page seems to suggest that Traefik only allows in-memory cache (which would eat RAM and not persist across reboots). You can probably run Nginx with this config inside a container for the caching, then use Traefik to handle requests to immich.your-domain.tld/map_proxy/* with the caching proxy container.

The closing parenthesis got caught into the link (at least with my client), turning it into a 404. You should add a space

I don't remember exactly, but the issue is about the existence of a button that makes beginners think a commit and a push are part of the same atomic operation. Not the order of the words on this button

Thanks for the suggestion, I cross-posted to these two communities.

Regarding Docker, I actually made two compose files : one for quickly getting a dev env running, and another one for deploying to (pre-)production.

I had a great time using Qubes. It made me learn about the Xen hypervisor and CoW filesystems.

However, if OP complains about build times being too long on their CPU, I'm not sure they will get Qubes running smoothly on the same hardware. I'm especially worried about every VM besides dom0 being software rendered.

That was the point of my comment, unless they wrote this ironically.

Sorry you went through the trouble of writing all of this explanation, I hope this is useful to someone else

How do you avoid conflicts happening in the first place?

Each time you send a packet over the internet, several routers handle this packet without touching the source and destination IP addresses.

There is nothing stopping him from configuring the VPS in a way that forwards packets from the home server, rewriting the destination IP (and optionally destination port as well) but leaving the source IP intact.

For outgoing packets, the VPS should rewrite the source (homeserver) IP and port and leave the destination intact.

With iptables, this is done with MASQUERADE rules.

This is pretty much how any NAT, including ones behind home routers, work.

You then configure the homeserver to use the VPS as a gateway over wireguard, which should achieve the desired result.