Perhyte

No idea about the Lemmy hosting bit, but I highly doubt that .com you got will renew at $1 going forward. Judging by this list it’ll most likely be $9+ after the first year.

At $1/year, the registrar you used is taking a loss because they pay more than that to the registry for it. They might be fine with that for the first year to get you in the door, but they’d presumably prefer to be profitable in the long term.

Clearly he’s actually the BBEG lich in disguise. Time for a phylactery hunt! ;)

Have you also enabled Bot Fight Mode? (There’s a setting to “Block AI bots” that seems useful in your situation)

If you don’t mind using a gibberish .xyz domain, why not an 1.111B class? ([6-9 digits].xyz for $0.99/year)

Any chance you’ve defined the new networks as “internal”? (using docker network create --internal on the CLI or internal: true in your docker-compose.yaml).

Because the symptoms you’re describing (no connectivity to stuff outside the new network, including the wider Internet) sound exactly like you did, but didn’t realize what that option does…

It also means that ALL traffic incoming on a specific port of that VPS can only go to exactly ONE private wireguard peer. You could avoid both of these issues by having the reverse proxy on the VPS (which is why cloudflare works the way it does), but I prefer my https endpoint to be on my own trusted hardware.

For TLS-based protocols like HTTPS you can run a reverse proxy on the VPS that only looks at the SNI (server name indication) which does not require the private key to be present on the VPS. That way you can run all your HTTPS endpoints on the same port without issue even if the backend server depends on the host name.

This StackOverflow thread shows how to set that up for a few different reverse proxies.

If there happens to be some mental TLS handshake RCE that comes up, chances are they are all using the same underlying TLS library so all will be susceptible…

Among common reverse proxies, I know of at least two underlying TLS stacks being used:

• Nginx uses OpenSSL.
  • This is probably the one you thought everyone was using, as it’s essentially considered to be the “default” TLS stack.
• Caddy uses crypto/tls from the Go standard library (which has its own implementation, it’s not just a wrapper around OpenSSL).
  • This is in all likelihood also the case for Traefik (and any other Go-based reverse proxies), though I did not check.

Aurora is no longer maintained, but it still works just fine. It’s a Windows app, so not web-accessible or anything, but it’s free. It only contains the SRD content by default (probably for legal reasons), but there’s at least one publicly-accessible elements repository for it that you can find using your favorite search engine.

That domain currently hosts a “this domain may be for sale” page, but it’s been registered since 2005 so it’s definitely not because of this post.

Additionally, HTTPS if very easy to set up nowadays and the certificates are free¹.

¹: Assuming you have a public domain name, but for ActivityPub that’s already a requirement due to the push nature of the protocol.

There are FOSS licenses (notably the GPL) that say that if you do resell (or otherwise redistribute) the software, you have to do so only under the same terms. (That is, you can’t sell a proprietary fork. But you could sell a fork under FOSS terms.) But none that say “no selling.”

For many companies (especially large ones), the GPL and similar copyleft licenses may as well mean “no selling”, because they won’t go near it for code that’s incorporated in their own software products. Which is why some projects have such a license but with a “or pay us to get a commercial license” alternative.

AFAIK docker-compose only puts the container names in DNS for other containers in the same stack (or in the same configured network, if applicable), not for the host system and not for other systems on the local LAN.

I have a similar setup.

Getting the DNS to return the right addresses is easy enough: you just set your records for subdomain * instead a specific subdomain, and then any subdomain that’s not explicitly configured will default to using the records for *.

Assuming you want to use Let’s Encrypt (or another ACME CA) you’ll probably want to make sure you use an ACME client that supports your DNS provider’s API (or switch DNS provider to one that has an API your client supports). That way you can get wildcard TLS certificates (so individual subdomains won’t still leak via Certificate Transparency logs). Configure your ACME client to use the Let’s Encrypt staging server until you see a wildcard certificate on your domains.

Some other stuff you’ll probably want:

• A reverse proxy to handle requests for those subdomains. I use Caddy, but basically any reverse proxy will do. The reason I like Caddy is that it has a built-in ACME client as well as a bunch of plugins for DNS providers including my preferred one. It’s a bit tricky to set this up with wildcard certificates (by default it likes to request individual subdomain certificates), but I got it working and it’s been running very smoothly since.
• To put a login screen before each service I’ve configured Caddy to only let visitors through to the real pages (or the error page, for unconfigured domains) if Authelia agrees.

You forgot one:

• They’ll quietly re-introduce it in another 6-18 months.

I believe on the free ARM instances you get 1Gbps per core (I’ve achieved over 2Gbps on my 4-core instance, which was probably limited by the other side of the connections). What you say may be correct for the AMD instances though.

I believe so, but in addition it is also a “the original meaning of ‘barbarian’ is non-Greek person” joke.

For the ARM instances they’re a gigabit per OCPU, which you can get 4 of for free (assuming you’re lucky enough with availability), so you can theoretically get 4Gbps for free.

Technically DNS will let you look up a host name from an IP address, but the catch is that it might not work: it’s not automatically configured. And even if it is configured you might not get all of the host names pointing at that address.

Very many webserver operators don’t bother adding the server’s host name to reverse DNS. For example, lemmy.world’s IP address does not map to any host name in reverse DNS, and google.com’s IP address maps to some completely different name for me, with no mention of Google in the returned name.

Also, many websites can be served from the same IP address, especially if they are hosted in the cloud. You are correct that someone snooping on the connection would still see the IP address, but if that points them at something like a webhosting company or a CDN (or some other server hosting many different sites) it still doesn’t really tell them which specific site is being accessed.

But yes, if the site you’re accessing is the only one hosted on that server then the snoop could potentially guess the host name. But even then: how would they know that’s the only site hosted there? If some site they’ve never even heard of uses the same IP address they would never know.

Without a VPN every host you connect to can approximate your location down to a few miles.

I just tried a few geo-IP lookups of my current IP address, and they all point to a location that (as the bird flies) is almost exactly 100 miles from my actual location. This is despite the ISP I’m using being headquartered in my current city, but maybe they have some infrastructure there?

On mobile data I instead get a location 90 miles away, and if I look up the IP address of another machine I know the exact location of, the result is 60 miles off.

60-100 miles is a pretty generous definition of “a few”.