Did you ask an AI to do the list for you? (no need to answer)

Intriguing.

What’s the mechanism for dealing with spammers?

In lemmy there’s a clear escalation path that will lead to either the spammer’s instance dealing with the issue or the instance itself being de-federated.

How would that work in a p2p system?

Each user having to individually block every spammer will work as well as it did for email back in the day.

It’s optimized for making money

Look at restic and/or borg first. Iff you have specific needs that they don’t address, then look at other things (including reviewing your requirements: chances are you are doing something wrong in that case).

It straight made up a powershell module, and method call. Completely made up, non existent.

It was just imagining the best way to accomplish the task: instead of complaining, you should have just asked it to give you the source code of that new module.

Your lack of faith in AI is hindering your coding ability.

(do I need to add the /s? no, right?)

If it’s for backup, zfs and btrfs can send incremental diffs quite efficiently (but of course you’ll have to use those on both ends).

Otherwise, both NFS and SMB are certainly viable.

I tried both but TBH I ended up just using SSHFS because I don’t care about becoming and NFS/SMB admin.

NFS and SMB are easy enough to setup, but then when you try to do user-level authentication… they aren’t as easy anymore.

Since I’m already managing SSH keys all over my machines, I feel like SSHFS makes much more sense for me.

AFAIU bluehost does not support the acme protocol, so you’ll either have to manage your certificate manually or (recommended!) move to a different dns registrar.

If you are wondering which provider you should switch to, basically all the serious ones will work… IDK if this is relevant for nginx, but here’s a list of the supported ones for the client I use https://go-acme.github.io/lego/dns/

If you are unsure and want to experiment before touching your current setup, you could register a new cheap domain (less than 1$, see https://tld-list.com/), use it for your tests, and then not renew it.

https://en.wikipedia.org/wiki/Knapsack_problem ?

Not sure if others already said this (I seem to see mostly comments explaining how to do it, but didn’t read them all), but, while it’s certainly feasible, you may not want to do that.

A router is the cornerstone of your network (if it goes down, so does the network) and if you are a self-hoster you’ll probably fiddle endlessly with your home server, and of course break it from time to time… the two things just don’t go well together.

Personally, I’d recommend getting some second-hand router appliance that can run openwrt and use that (make sure to check the flashing procedure before deciding what to buy - some are easier than others). Or you could get a dedicated x86 machine… probably overkill though.

Seems fun :)

Beware that the check passport screen and the one before it may make it look like a papers please clone (which it definitely seems not to be after looking/reading further) - maybe move them further down in presentation order?

IMHO Ansible isn’t much different than a bash script… it has the advantage of being “declarative” (in quotes because it’s not actually declarative at all: it just has higher-level abstractions that aggregate common sysadmin CLI operations/patterns in “declarative-sounding” tasks), but it also has the disadvantage of becoming extremely convoluted the moment you need any custom logic whatsoever (yes, you can write a python extension, but you can do the same starting with a bash script too).

Also, you basically can’t use ansible unless your target system has python (technically you can, but in practice all the useful stuff needs python), meaning that if you use a distro that doesn’t come with python per default (eg. alpine) you’ll have to manually install it or write some sort of pythonless prelude to your ansible script that does that for you, and that if your target can’t run python (eg. openwrt on your very much resource-constrained wifi APs) ansible is out of the question (technically you can use it, but it’s much more complex than not using it).

My two cents about configuration management for the homelab:

• whatever you use, make sure it’s something you re-read often: it will become complex and you will forget everything about it
• keep in mind that you’ll have to re-test/update your scripts at least everytime your distro version changes (eg. if you upgrade from ubuntu 22.04 to 24.04) and ideally every time one of your configured services changes (because the format of their config files may in theory change too)
• if you can cope with a rolling-style distro, take a look at nix instead of “traditional” configuration management: nixos configuration is declarative and (in theory) guarantees that you won’t ever need to recheck or update your config when updating (in reality, you’ll occasionally have to edit your config, but the OS will tell you so it’s not like you can unknowingly break stuff).

BTW, nixos is also not beginner-friendly in the least and all in all badly documented (documentation is extensive but unfriendly and somewhat disorganized)… good luck with that :)