That is a cool feature, but that would mean that all of the web traffic would get returned to my local network (assuming that the server is set up on a remote VPS), which I really don't want to have happen. There is also the added downtime potential cause by the added point of failure of the GPU being hosted in a much more volatile environment (ie not, for example, a tier 3 data center).
If some new spam account signs up on Lemmy.world and posts to lemm.ee, then if it's removed by an admin on your instance it is only removed for people on your instance. Everyone else still sees it as your instance is not hosting either the community or the user so it can't federate our anything to deal with it. The lemm.ee instance could remove the post or comment with the spam in a way that federates out to other instances, but can't ban the user except for on their instance. Only the Lemmy.world instance can ban the user in a way that federates out to other instances.
This make me think that we should maintain a community curated blocklist in, for example, a Git repository. It could be a list of usernames, and/or a list of instances that are known to be spam that gets updated as new accounts and instances are discovered. Then any instance owner can simply pull the most current version of the blocklist (this could even be done automatically). Once the originating instance blocks the malicious account, they can be removed from the list. This also gives those who have been blocked a centralized method to appeal the block (eg open an issue to create an appeal).
I would honestly have expected something like this to already exist. I think it's partly the purpose of Fediseer, but I'm not completely sure.
[Using a hosting service] makes you a more difficult target for attacks but also involves your information getting out into the world in direct connection to your instance.
I'm not sure I understand how one's data would be leaked by the hoster.
I've never hosted a public facing social media service. I have a few years experience hosting a number of my own personal services, but they aren't at the scale of a public facing Lemmy instance.
Do you mean also disabling thumbnails? IIUC, pict-rs handles all thumbnail generation [1]. The reason I point this out is that simply disabling image uploads won't itself stop the generation of thumbnails [2]. There's also the question of storing/caching images that come from federated servers.
One thing to note, I wasn’t able to get it running on a VPS because it requires some sort of GPU.
This is good to know. I know that you can get a VPS with a GPU, but they're usually rather pricey. I wonder if there's one where the GPU's are shared, and you only get billed by how much the GPU is used. So if there is an image upload, the GPU would kick on to check it, you get billed for that GPU time, then it turns off and waits for the next image upload.
If your instance freely hosts whatever without any oversight, word will spread and all of a sudden you’re hosting all sorts of bad stuff. It’s not technically illegal if you don’t know about it, but I personally don’t want anything to do with that.
Yeah, this is my primary concern. I'm hoping that there are established best practices for handling the majority of this sort of unwanted content.
Question/Answer: Instance admins can set an arbitrary question which needs to be answered in order to create an account. This is often used to prevent spam bots from signing up. After submitting the form, you will need to wait for some time until the answer is approved manually before you can login.
That is a cool feature, but that would mean that all of the web traffic would get returned to my local network (assuming that the server is set up on a remote VPS), which I really don't want to have happen. There is also the added downtime potential cause by the added point of failure of the GPU being hosted in a much more volatile environment (ie not, for example, a tier 3 data center).