Great news! Also thanks for providing the follow-up, hopefully it helps people who use Unraid in the future.

You can do all those things with proper routing and there is no difference from mobile devices (as long as they use DHCP and what mobile device wouldn’t?). What I’m suggesting does not change anything on the public side. You still authenticate publicly to renew your certificates. You still give the same certificates to both public and local networks. They’re still valid. Nothing changes.

The only difference is that when you’re local, your DNS gives you the correct local IP address where that service is hosted, say, 192.168.12.34 instead of using public DNS, getting an external IP that’s on the wrong side of the router, and having to go outside your own network and come back in. Hairpin is like that simpsons episode where Abe goes in the revolving door, takes off his hat, puts his hat back on, and goes back out the same revolving door in the span of 2 seconds. It’s pointless, why are you doing that? If you didn’t want to be on the outside of the network, why are you going to the outside of the network first? Just stay inside the network. Get the right IP. No hairpin routing needed. No certificate madness needed. Everything just works the way its supposed to (because this is in fact the way it’s supposed to work)

Convenience is great until it becomes inconvenient. But that’s a journey we all make :)

I’m not too familiar with unraid but from a little research I just did it seems like you’re right. That does seem like a really unfortunate design decision on their part, although it seems like the unraid fans defend it. Obviously, I guess I cannot be an unraid fan, and I probably can’t help you in that case. If it were me, I would try to move unraid to its own port (like all the other services) and install a proxy I control onto port 443 in its place, and treat it like any other service. But I have no idea if that is possible or practical in unraid. I do make opinionated choices and my opinion is that unraid is wrong here. Oh well.

I’d argue that your internally hosted site should not be published on ports other than 80/443. Published is the key word here, because the sites themselves can run on whatever port you want and if you want to access them directly on that port you can, but when you’re publishing them and exposing them to the public you don’t want to be dealing with dozens of different services each implementing their own TLS stack and certificate authorities and using god-knows-what rules for security and authentication. You use a proxy server to publish them properly. And there’s no reason you can’t or shouldn’t use that same interface internally too. Even though you technically might be able to directly access the actual ports the services are running on on your local network, you really probably shouldn’t, for a lot of reasons, and if you can, maybe consider locking that down and making those services ONLY listen on 127.0.0.1 or isolated docker networks so nothing outside the proxy host itself can reach them.

If you don’t want your services to listen on 80/443 themselves that’s reasonable and good practice, but something should be, and it should handle those ports responsibly and authoritatively to direct incoming traffic where it needs to go no matter the source. Even if (or especially if) you need to share that port with various other services for some reason, then either way you need it to operate that port as a proxy (caddy, nginx, even Apache can all do this easily). 443 is the https port, and in the https-only world we should all be living in, all https traffic should be using that port at least in public, and the https TLS connection should be properly terminated at that port by a service designed to do this. This simplifies all sorts of things, including domain name management and certificate management.

tl;dr You should have a proxy that publishes all your services on port 443 according to their domain name. When https://photos.mydomain.com/ comes in, it hits port 443 and the service on port 443 sees it’s looking for “photos”, handles the certificates for photos, and then decides that immich is where it is going and proxies it there, which is none of anyone else’s business. Everyone, internal or external, goes through the same, consistent, and secure port 443 entrance to your actual web of services.

Nextcloud, CalDAV, Thunderbird.

XMPP/Jabber and Matrix both support full end-to-end encryption. Matrix has more cool modern features and slicker UI but has a brutally complex architecture if you want to self-host it. Matrix.org is available though, but since it’s pretty centralized it’s likely to get blocked. XMPP is simple and self-hostable. Both protocols are pretty niche, and except for matrix.org most of the providers that use the protocols are extremely niche. I would say XMPP is on the whole significantly more niche, though. My condolences on your family being in Russia. The warmongering fascists must be stopped. Good luck, hopefully everyone can stay safe.

Opinionated wall of text incoming:

Hairpin is an annoying hack. It happens and is necessary when you are getting a public IP from DNS but the service is not actually listening on that address itself, because the router owns that address, and that address is actually on the other side of the router, the public-facing side, not the side you’re on, so now you have to go out to the public side of the router, turn around (the hairpin turn) and come back in as if you were a public user in order to get to a service that was literally sitting right next to you (on the private side) the whole time.

What you should do instead: You should have your own internal DNS for your own personal network that resolves the DNS properly within the context of that network. This avoids needing to use hairpin at all, because your traffic is never trying to go out to the public internet in the first place. If you get the correct, context-specific best path IP to your services at all times, you don’t have to use the naive, public IP for immich that doesn’t even actually exist on your local network.

The terminology around all this is confusing and sometimes stupid because private networks behind NAT never really existed when DNS was invented, and a lot of people deal with it in stupid and overcomplicated ways. If this same DNS server were then also going to be shared and used publicly to host your own domain names to other people, you would need a thing called “split zones” or “split DNS” but you don’t need to do that and you should avoid that too. Keep private DNS private, and leave public DNS out in public. Separate them intentionally and deliberately.

If you are getting the public IP for your Immich, then you are using its public DNS. I will try and make it simple for you, the way I think everyone should do it:

Your LAN/VPN environment is private. It should have its own dedicated authoritative private DNS server whose purpose is limited to completely and comprehensively servicing all the DNS IP lookup needs of that LAN/VPN environment and being the sole source of truth within that network. Often, the local network’s DNS is already correctly configured and provided by your router to handle all public IPs, and this is usually completely fine for self-hosting. What matters is that you should be able to add custom IP addresses to it, and it should be private to your network. Nobody else should have access to this DNS configuration, not because it’s really important for security but just because it is irrelevant outside the context of your local network, which is usually exactly what your router DNS provides. Your internal network DNS is responsible for two things within that environment:

• Providing the correct local (private) IP address for traffic to local services that belongs only on your network.
• Providing official public IP addresses for any OTHER things outside that local network like any normal DNS server (typically accomplished by DNS forwarding to your ISP’s servers or Google/Cloudflare DNS servers, or resolving it from the root servers directly, called recursive DNS) Almost any router or DNS server will do this by default, if you’re accessing Lemmy you’re getting Lemmy’s public IP from your router’s DNS configuration.

You just have to implement and maintain the first part, usually in your router’s configuration. If you want more control or consistency over the DNS your local network is using it can also be self-hosted with something small like dnsmasq, or even big old granddaddy bind/named (not as complex as it seems and very standardized). Either way, that’s your responsibility, and once you’re providing correct local IPs for Immich on your local DNS (outside your network, you and the public will still use public DNS and get the public IP) everything will just work.

Hairpin may feel convenient. It’s not, it’s a workaround for a misconfiguration. Having private DNS that is separate and distinct from public DNS may feel like duplication of effort, but it’s not, it’s fundamental to even having a local network and puts you in the drivers seat for the layout of that network. Take responsibility for it instead of letting hairpin fix your mess.

This is the kind of nuanced usage of AI I like to see. Some would argue it’s not ideal to use any AI at all, and I agree, but we don’t live in an ideal world and I think this is realistically fine. AI writes better tests and docs than the ones I never write. Sure, maybe they’re not great objectively speaking, but they’re not worse than nothing. It’s better at keeping them up to date than I am too. Which is also probably not great, but strictly better than me.

Self host your own code repo. Forgejo is adding activitypub and federation features, not sure how far long they are, but someday if enough people start self-hosting we might have a viable decentralized way to collaborate on and contribute to each others’ projects.

If it’s strictly for personal use, Nextcloud can do this easily (no upload required since the client handles the sync), although it’s a very heavyweight way to do it and for security reasons most people probably have Nextcloud set up behind a VPN-wall like Tailscale or something so it may not work for you.

However, it technically has a share link feature that does exactly this. If you’re using the desktop or mobile client you just have to put it in one of Nextcloud’s sync folders and then right click on it or whatever to get a share link to the file. You can also do it through the web UI (both the upload itself and getting the link to it) You can make the share link public and permanent so anyone who can access the Nextcloud server can get access to that file through the link.

Worth considering if you already have a Nextcloud instance. Alternately, if you aren’t already using Nextcloud for sensitive personal files, and just want a repository of silly meme images you can share freely, giving public access to it (it’s still locked behind an account for upload and general access) isn’t that much of a security concern and then your public links should work just fine.

If you want something that is more of a social media site and image gallery like Imgur is, maybe Immich can handle some of that, but if your goal is simply sharing image file links, I’d focus on looking for things that are more for sharing files, since images are just files and it doesn’t sound like you need all the complex image-specific handling really.

Agree, I don’t blame the people becoming cynical and distrustful, I think that’s a totally rational and valid response to the current situation. I blame the people (government representatives and companies, more to the point) who are making this the situation in the first place.

I don’t want to live in a world where we trust no-one and nothing. But it’s delusional not to see that we do live in a world that is rapidly moving that direction. We need to do something (a lot of things) to stop it, but we also can’t pretend it’s not happening.

No, you are definitely not the only one. I tend to be more judgemental of projects that contain prolific use of emojis in general, but that has been ongoing since before AI became popular.

Running it as a VM or even on a server that is running other services and potentially competing for I/O or memory bandwidth also introduces many other potential sources of inefficiency. I always recommend running a firewall on dedicated bare metal hardware, it is a very specialized task with very particular requirements on behalf of both the hardware and the software and it has very little tolerance for other sources of latency or delays. That doesn’t mean you need to use a pre-built appliance, but it does explain why it’s so common, and running it on a VM on a server that is doing other stuff is likely contributing to your issues significantly.

Personally, I run my firewall/router on a very stripped-down Debian with almost no non-essential services and a custom built kernel. I hand-picked a multi-port PCIe x4 Intel NIC with good Linux compatibility and drivers, and I’m using foomuuri to handle the routing and kea to handle DHCP/DNS for my internal network. This is a very minimal, bare-bones configuration and I wouldn’t really recommend it unless you really know what you’re doing, and it’s absolutely not “idiot mode networking” and if that’s what you want you’re going to have a real bad time if you try to follow in my footsteps, because I am a very different kind of idiot. But it works for me, so it’s proof that it is possible.

I consider the article’s criticisms of SMTP, HTTP, XMPP, etc. (and IRC which was not mentioned but falls in the same category) to be positive and desirable traits and I think it’s a shame that the article characterizes them negatively. HTTP’s job is not to prevent corporate takeover of the web and I don’t think it should be. That’s our job, as people. The protocol’s job is to remain neutral so that when corporate takeover of the web happens, HTTP is still there, open to everybody, providing an offramp to escape it, because it’s neutral. It doesn’t belong to the corporations. It belongs to everybody. They can try to take it over if they wish, embrace and extend, but they can’t extinguish a fire that’s smoldering underground no matter how hard they try. It will always be there, ready to flare up at a moment’s notice. The original is always still there ready for us to revert to using it at any time.

And many of us already have. Fuck Google, fuck Cloudflare, fuck AWS, they’ll never take the web from us.

Anything you post on the internet is public knowledge forever. End of discussion. Most people won’t care at all, in most cases almost nobody or perhaps even literally nobody will ever even see it, but the harder you try to hide it, the more the Streisand Effect will magnify it until eventually everyone knows about it.

Anyone telling you they’ll delete your data from the internet without clarifying that it is in fact impossible, is at worst deliberately lying to you usually for their own benefit, and at best making a promise they literally have zero ability to keep.

I would hope that Fediverse services will never lie to you and tell you your data is deleted, because it can’t be.

I think ActivityPub is closer to the right answer than ATProto, and ActivityPub’s issues (though many, as the author notes) are more manageable in the long run. I think the article makes a good analysis of the fundamental differences, but is a bit glib in referring to Piefed’s topics and discussion merging as a “joyful mess”. It’s not a mess at all. It’s making order out of the chaos, and it’s the right way to build on top of ActivityPub into something that is actually fluid enough for users to actually use.

Mailing lists were built on top of federated email in much the same way, and they formed enduring, resilient, well-structured communities, some that continue to this day (the LKML being perhaps the most notorious)

I think ATProto makes creating enduring communities too difficult, and BlackSky illustrates that perfectly. The author’s criticism of ActivityPub, on the other hand, seems to be that it makes creating communities too easy, and this results in a “mess”. I disagree, I think the mess is a necessary and inevitable part of having community. Communities are messy. They fracture and schism, they rejoin and reshape themselves. That’s normal. It is the responsibility of the software to make sense of the mess and make it presentable, and with ActivityPub, that is not only possible, it is happening. Piefed is the present example. I expect there will be more examples, and a wider variety of them, as the ecosystem continues to develop.

I think the biggest thing that ActivityPub still needs is better portability, for both users and communities, to allow moving servers more seamlessly. The “Personal Data Server” of Bluesky is not a bad concept, although I don’t love their implementation. I think ActivityPub can find a way to handle portability even better, but it doesn’t seem like it’s been a priority, and that’s fine. But it will need to happen eventually.

Split DNS typically refers to splitting the DNS results of a single, existing DNS server depending on who asks it, which is not what you want here, because that same server would be serving both external clients and internal ones and would need to differentiate between them.

You want an internal DNS server JUST for your own LAN, and its full-time job is very simple: to have all your local machines pointed at it for DNS, then it will either pretend it’s authoritative and return the proper local IPs for whatever name you ask it for that’s supposed to be on the local network, OR it forwards any other requests it doesn’t consider itself “authoritative” for onwards to your Adguard or other DNS provider to get a real authoritative external IP in response.

The very simplest option for a bare-bones, basic DNS server that will do what you need is dnsmasq. Here is the default sample config for reference. Simply leave all “dhcp” related settings in the config commented out and you’ll probably also want to set:

• no-hosts (won’t use the /etc/hosts file)
• resolv-file (an /etc/resolv.conf style file that tells it what actual nameservers to use for all other queries)
• and either address=/sub.domain.tld/192.168.1.1 (for the subdomain and everything under it)
• or host-record=sub.domain.tld,192.168.1.1 for only that specific subdomain exactly

Then change all your local DNS servers to point at dnsmasq’s IP address (you typically would do this at whatever device is handing out IPs on your network with DHCP, for example the router)

I think that’s pretty much it.

The purpose of the health check is to allow docker itself to talk to whatever service is running on the container to make sure it’s always responding happily, connected to everything it needs to be connected to for proper operation, and is not overloaded or stuck somehow.

Docker does this by pretending to be a web browser, and going to the specified “health check URL”. The key thing I think you’re missing here is that the health check URL is supposed to be a URL that, ideally, runs on your container and does some meaningful checks on the health of your service, or at the very least, proves that when you connect to it, it is able to serve up a working static page or login page or something (which doesn’t actually prove it’s working completely, but is often good enough)

Now, you’re probably wondering why this isn’t automatic, and the answer is because there’s no standard “health check URL” that fits all services. Not all services even respond to URLs at all, and the ones that do may have different URLs for their health checks, they may need different hostnames to be used, etc.

By setting health check URL to example.com, basically what you’re doing is constantly testing whether the real-world website https://example.com/ way over there somewhere is working, and as long as it is, docker assumes your container is fine. Which it might be, or it might not be, it has no idea and you have no idea, because it’s not even attempting to connect to the container at all, it’s going to the URL you specified, which is way out there on the internet somewhere, and this effectively does nothing useful for you.

It’s understandable why you probably thought this made sense, that it was testing network connectivity or something, but that is not the purpose of the health check URL, and if you don’t have a meaningful URL to check, you can probably just omit or disable the healthcheck in this case. Docker only uses it to decide if it needs to restart the container or alert you of the failure.

Seems pretty good, using the latest version of ollama (downloaded the default Q4 from ollama) and then popped it into Codex with this config.toml:

model = "qwen3-coder-next:Q4_K_M"
model_provider = "ollama"
model_reasoning_effort = "medium"

[model_providers.ollama]
name = "Ollama"
base_url = "http://localhost:11434/v1"

[analytics]
enabled = false

Works well in Codex CLI and VScode Codex IDE plugin. Did not work well with Kilo Code or Roo plugins unfortunately (but I have yet to find much that does).

I am not an expert, this may not be the best way, I don’t know… just sharing my experience for the other non-experts out there.