You’re right I don’t think it can, can only advertise explicit labels.

Please note that to use “bcrypt” for htpasswd_encryption you need the bcrypt python module installed. Some distributions of radicale (eg. some docker images) don’t have it.

It’s fairly safe to set it to “md5” instead. It does not mean plain MD5 (one iteration), it does several hundred rounds of MD5 plus a salt.

For the curious, the advantage of bcrypt over a single-iteration, fast hash like MD5 is that bcrypt lets you set the hashing effort, while MD5’s goal is to do it as fast as possible.

This becomes relevant when someone steals your password file and tries to brute force it by hashing a bunch of dictionary words and random strings (plus a bunch of salts) until something matches. A fast single-iteration hash like MD5 will let them do that much faster than a bcrypt hash set to a higher effort; it can mean the difference between finding a password in one week vs finding one in 100 years. That’s what the hundreds-of-iterations MD5 is trying to achieve, it’s a “poor man’s bcrypt”.

Add mTLS to the reverse proxy and to the Immich client app and forbid access without it.

The mTLS certs can be self-generated. There are tutorials for generating your own CA and individual mTLS certs for each device. Then you put the ca.pem file in a place accessable by NPM and add a couple of commands to the “Advanced” tab of the Immich proxy host, and you put the mTLS cert on the phone and load it into the Immich app.

mTLS is a super strong method, not only does it serve as great authentication for that particular device, it also checks the TLS connection for tampering so it can’t be hijacked even if somehow you get rogue certificates loaded on your phone, you can revoke certs if your phone gets lost or stolen etc.

It supports it on the iOS client as well but last time I tried it would always lose the mTLS setting on its own after a while. I had to resort to the other method they offer, secret key in a custom HTTP header.

DAVx5 also includes good security, like the ability to use mTLS to secure your access to Radicale adequately even if you expose it over the open Internet. It’s also being actively developed, with updates coming out every few weeks.

InfCloud is the last and only functional, standalone, web-based CalDAV frontend currently in existence. It doesn’t really matter how crap it is because there’s no alternative. And besides CalDAV/CardDAV are not exactly rapidly-evolving anymore.

There are a handful of alternative frontends bundled with other webapps, for example Nextcloud includes one, but if you don’t want to install Nextcloud just for that you’re stuck with InfCloud.

I really wish someone would make a modern standalone webapp for this but no luck so far.

Having worked at some point on some calendar interfaces I can appreciate why, because they’re super intricate and difficult.

Start by using a 3rd party contacts app (or dialer+contacts as they usually come, at least on Android). Google’s Contacts app only works with Google.

The 3rd party app should let you explicitly select which sources of contacts you want to use. After you set up DAVx5 you should see it available as a source.

The app I use (True Phone, com.hb.dialer.free) shows a list of all sources under “Settings > Contacts > Contacts to show” and you can check/uncheck the ones you want.

I guess this can be useful when you can’t change DNS on the local router.

But wouldn’t announcing *.local.domain for the server that Traefik runs on accomplish the same?

Isn’t this what I just did? mydomain.eu.cc

I mean the second part from the end (.eu.). That’s not yours, and that means that the mydomain. part can dissapear at any time. The owner can also do all kinds of unpleasant things that can affect your online presence.

By “your own” domain I mean getting something of your own in that 2nd spot instead of “eu”. It doesn’t have to be on the .cc registry, it can be any established TLD like .com, .net, .org, it can be a country TLD aka ccTLD like .cc, .nl, .de and so on, or it can be a so-called “novelty” domain like .dev.

Having your own domain means you can own it in perpetuity (well… old, established TLDs are better at this than novely TLDs) and have much better control over it.

Visit a domain registrar like Porkbun and have a look through their TLDs, check some prices, the privacy of your personal data etc.

Avoid registries that allow “premium” domains, it means that the registry can suddenly decide that the domain you own is very cool and force you to pay hundreds or thousands for the next renewal or lose it.

Wouldn’t connecting through an existing fedi server also enforce its blocklist down to me?

I’m not entirely sure on how you propose to use your server: if you just want to read stuff or also want to be able to post.

Your server can do things with another server in two ways, by exposing an open port and allowing the other server to do stuff locally through that port, or by connecting to a port opened on the other server and doing stuff there.

If the fediverse protocol mandates having a local port open to do stuff like posting, it may be impossible to avoid doing it.

First of all I would suggest getting your own domain. There’s many TLDs and ccTLDs that will let you get a domain for $10/year or much less.

If you don’t want to pay then at least get a subdomain from somewhere reliable. Preferably a DNS service because you also get DNS management this way. My recommendation is DeSEC because it’s a German, privacy-oriented non-profit and it has a modern interface and modern features like an API, security tokens, support for recent record types, DNSSEC etc. And if you later decide to get a paid domain you can keep using DeSEC for it very easily.

Secondly, does your fediverse single-user server really need to be exposed to the internet to get updates? Can’t it pull them from other servers? That way you would reduce your risk a lot.

An unauthenticated tunnel is still an ingress path same as an open port, just with more steps.

Worth noting that FreeDNS domains can be a mixed bag. Anybody can add or remove the base domains at any time because they’re lended freely. The owner can also arbitrarily decide to delete your subdomain, or reserve it for themselves, or even hijack its use, its TLS certs etc.

The top 7 domains listed there (including mooo.com) as owned by “josh” are somewhat better than the others because Josh is the owner of FreeDNS. So those domains will be around for as long as FreeDNS will, and you know Josh is not gonna hijack your subdomain. But be wary of using any other domain there (or putting your own domain up for use).

Should probably note that “DMZ” in this context means a separate VLAN. Because the term is also commonly used to mean “DMZ host” where a router exposes a machine directly to the Internet. You want the former, not the latter.

But, more to the point, a beginner really shouldn’t be exposing anything to the Internet. 🙂 Running a public service as a person who doesn’t know how domains work will not end well.

I think what OP means is that you can mix using an external email provider with storing your own email archive + an IMAP server + a webmail app. You can let the provider deal with the IP reputation and all that pain and just use their SMTP and IMAP to send email and pull to your local server, respectively. If you use your own domain you can also switch the provider in 10 minutes by simply changing your DNS records and retain the same address.

The hard part for me when giving up Gmail wasn’t the stuff above, it was tracking down all the places I was subscribed as @gmail.com and replacing it with @my.domain addresses. That took about 6 months. The local pull + IMAP + webmail took a weekend to set up.

Short answer: IMAP and the mbsync tool (aka “isync”). It can sync between two IMAP accounts or between IMAP and local storage (either/both ways).

If you just want syncing between two IMAP accounts there’s also imapsync, which is available both as a program and as an online service run by the guy who maintains the program, priced as “pay what you want”, which can migrate your inbox on the fly to another service.

What I’ve done myself is to run mbsync periodically (made myself a custom Alpine image with cron and mbsync) to bring emails over. Added an IMAP server container on top of the local copy of the emails (tons of options, Dovecot is popular). Added a webmail app behind reverse proxy, talking to the IMAP server on a private docker network (Roundcube). And a Borg Backup job to take an extra backup (incremental, deduplicated and encrypted) of the email archive.

In theory I could also connect the webmail to the SMTP of whatever email provider I’m currently using and be able to use it to also send. I don’t do that because I have email clients connected to the provider on both desktop and phone so it’s not a requirement, but I could if I wanted to.

This approach lets me periodically trim down the emails stored at the provider to only the most recent. This lets me also use providers that offer small amounts of storage. My recent emails are available instantly through IMAP to the provider. Starting within last 24h and going back forever they’re available at the archive webmail.

I can switch email providers at any time as fast as DNS records propagate (because I use @my.own.domains) and as fast as I can update the IMAP/SMTP credentials for my phone/desktop/mbsync.

CF tunnels are a way to bypass NAT but they are not really secure. There’s no authentication, just a WAF and some bot detection. It’s not really comparable with a VPN or Tailscale.

FWIW, Tailscale is a private company that’s been doing well, so it hasn’t been going down the enshittification route yet. There’s also headscale, which they support and which will serve as the canary in the mine if they ever start souring the deal.

Meanwhile, I see no reason not to use a perfectly good service just because it might be gone someday.

The unfortunate reality is that some people will buy anything that expires, on the remote chance someone might be interested. If they’re set on doing that there’s nothing you can do, they will grab it and block it for at least one more year.

IMHO the best thing you can do is nothing. I mean nothing beyond discreetly checking the domain state in whois. Don’t inquire explicitly about the domain. Don’t use the WHOIS form on websites you don’t trust to exploit such queries into grabbing domains themselves.

You can use whois from the command line (best way). Alternatively, the TLD registry will have a WHOIS form on their official website.

If you don’t generate any apparent interest they will eventually let the domain lapse. Check back a year from now.

rsync -avxH will copy the files between drives.

You can simply mount the new drive in the same place as the old one after the copy, that way you don’t have to change any paths.

If by “easy” you mean someone else already spent 5 years and a nice chunk of cash training a model for it, which you get to use. And if you accept that it will not be accurate across all possible species and environments, only very specific subsets.