I host a few sites and I haven’t had a problem yet. Sure, logs suggest a majority of traffic is bots, but the cheap VPS I’m hosting on hasn’t melted so I haven’t been motivated to do anything about it.
Lemmy is particularly susceptible. Hosting a static site with a limited number of pages is fine. Lemmy needs to check all posts, find the votes, sort them, and compile the page. It does that for practically every page load, and so loading a page once is quite “expensive”.
Then add on to that the almost unlimited pages of content for bots to crawl through, bots just get caught endlessly scraping pages. Even powerful servers struggle, which is why most Lemmy instances have implemented some sort of protection against bots.
All the logged-out views in Lemmy should be cached, otherwise you’re going to have scalability problems.
edit: you can probably do this without even touching the Lemmy code. There’s already nginx serving lemmy.ca, which can be configured to cache it and respect the Vary header. (I suspect the admins are already way ahead of me here, but I just wanted to share the general approach, which is pretty universal.)
4chan has been ‘static’ forever, the backend builds each page every ~15s, pages served to users are always static. It’s ‘justwerked’ for 20 years now on a shoestring.
Lemmy is built as a separate web app and back end that communicate via APIs. It makes it easy to support apps and alternate web interfaces, unlike Piefed which only started adding an API reasonably recently and doesn’t have a fraction of the eco system that Lemmy has.
But I think an important part is that Lemmy is explicitly customised for users. While bots are getting the same logged out version, the intent of Lemmy is not to be scraped by bots but it’s to be custom for each user. You’re supposed to log in, subscribe to communities you like, block people you don’t like, and have posts you’ve already seen hidden (if you set this in your settings).
Serving a custom page to each user based on their settings, blocks, and subscriptions isn’t really suited to static pages.
Sounds like 4chan rolled their own server-side page cache. It probably made more sense for 4chan to do that then, back when the internet was still pretty new.
Nowadays there are a few packages that perform a similar function, like Varnish. Varnish picks up requests from the internet and where possible, it returns the response as static HTML from its own cache.
There are other types of caching at different stages of the request lifecycle that can reduce the gap between dynamic and static website performance.
There were attempts to rewrite imageboard software with modern dynamic frameworks and caching infrastructure, but it scaled worse than oldschool index and thread html regeneration on post event, and was cancelled. The effort was called something like Infinity, by 8chan.
I think this is the photography site he’s talking about.
He mentioned “so many scrapers hit my site that it saturated my upload with generated content feeding the them.” which seemed unusual to me. I’m not sure why such a site would have a public upload. It doesn’t feel like a site that would have a technical challenge with the scrapers, but I also get the impression the main issue is the thought of hosting all his photos just for AI scrapers to train their image generation models.
Parts will be cached but it’s per instance. For a 100 user instance, what are the chances that a recent cache of All page 74 is available? Bots are crawling every page, and most pages are content from last month, last year, or 3 years ago.
I would expect Lemmy instances to have some limiters set for guest connections, especially for ones coming from datacenters. Like, it should be easy and senseful to only link and cache up to All page 10, or Hot page 5, and refuse guest loads of anything beyond that.
Ultimately this has been a recent-ish problem, and Lemmy simply doesn’t have this sort of function yet. It’s a goo thought, though.
As the other commenter said, bad bots are not easy to tell. OpenAI, Anthropic, etc identify themselves so are easier to block. They also tend to respect a robots.txt. The issue is the b=bots that don’t limit themselves, and route through hundreds of residential IPs. You literally see dozens of IPs all with approximately the same number of requests, like 80,000 per IP. If you block them they route through others. They seem to have an endless number of residential IPs to route through, presumably due to the things you see on Lemmy about the TV apps that proxy traffic even when the TV is off. I notice a lot via South American or South East Asian countries, which lead me to suspect at least some of these residential IPs are proxying through compromised devices that might not have up to date security patches available.
I dont believe it is that easy to tell if an IP is coming from a data center, unfortunately. To some extent you can tell its location with the geolocation database, but that is not authoritative and can be wrong or even contain intentional falsehoods. You can also see what is adjacent to it and make guesses that way, but that is often inconclusive due to common tunneling protocols like MPLS.
I believe the only remotely accurate way to tell if a connection is a bot is to use modules that detect bot behavior and redirect what it detects. Some users have even made infinitely recursive “traps” for bots that do not respect their robots.text file, which make their web page seem infinite so it scrapes forever over these fake pages that are less work to host than they are for the bot to parse through.
It is a very tough problem with few easy solutions. It will likely result in an arms race much like ads and ad blockers, hackers and firewalls, etc. It has so far, anyway.
I dont believe it is that easy to tell if an IP is coming from a data center
The bad scraping bots are proxying their traffic via resiential IPs, so it doesn’t even matter. Presumably this is through the free TV apps that you see mentioned on Lemmy occasionally, or through compromised devices.
I host a few sites and I haven’t had a problem yet. Sure, logs suggest a majority of traffic is bots, but the cheap VPS I’m hosting on hasn’t melted so I haven’t been motivated to do anything about it.
Lemmy is particularly susceptible. Hosting a static site with a limited number of pages is fine. Lemmy needs to check all posts, find the votes, sort them, and compile the page. It does that for practically every page load, and so loading a page once is quite “expensive”.
Then add on to that the almost unlimited pages of content for bots to crawl through, bots just get caught endlessly scraping pages. Even powerful servers struggle, which is why most Lemmy instances have implemented some sort of protection against bots.
All the logged-out views in Lemmy should be cached, otherwise you’re going to have scalability problems. edit: you can probably do this without even touching the Lemmy code. There’s already nginx serving lemmy.ca, which can be configured to cache it and respect the Vary header. (I suspect the admins are already way ahead of me here, but I just wanted to share the general approach, which is pretty universal.)
Why not just use more static pages?
4chan has been ‘static’ forever, the backend builds each page every ~15s, pages served to users are always static. It’s ‘justwerked’ for 20 years now on a shoestring.
Lemmy is built as a separate web app and back end that communicate via APIs. It makes it easy to support apps and alternate web interfaces, unlike Piefed which only started adding an API reasonably recently and doesn’t have a fraction of the eco system that Lemmy has.
But I think an important part is that Lemmy is explicitly customised for users. While bots are getting the same logged out version, the intent of Lemmy is not to be scraped by bots but it’s to be custom for each user. You’re supposed to log in, subscribe to communities you like, block people you don’t like, and have posts you’ve already seen hidden (if you set this in your settings).
Serving a custom page to each user based on their settings, blocks, and subscriptions isn’t really suited to static pages.
Sounds like 4chan rolled their own server-side page cache. It probably made more sense for 4chan to do that then, back when the internet was still pretty new.
Nowadays there are a few packages that perform a similar function, like Varnish. Varnish picks up requests from the internet and where possible, it returns the response as static HTML from its own cache.
There are other types of caching at different stages of the request lifecycle that can reduce the gap between dynamic and static website performance.
There were attempts to rewrite imageboard software with modern dynamic frameworks and caching infrastructure, but it scaled worse than oldschool index and thread html regeneration on post event, and was cancelled. The effort was called something like Infinity, by 8chan.
Back in the day people used Squid for that if they needed it.
I believe you, but the linked article is not about hosting Lemmy.
No it’s not, it was more of a tangential comment.
I think this is the photography site he’s talking about.
He mentioned “so many scrapers hit my site that it saturated my upload with generated content feeding the them.” which seemed unusual to me. I’m not sure why such a site would have a public upload. It doesn’t feel like a site that would have a technical challenge with the scrapers, but I also get the impression the main issue is the thought of hosting all his photos just for AI scrapers to train their image generation models.
I interpreted that as LP having the site running in their basement, and responding to scrapers saturates their outgoing bandwidth.
Ah that would make more sense!
It doesn’t need to. Like any similar site, it can cache a lot of that in databases like redis, or cache the rendered page in part or in whole.
Parts will be cached but it’s per instance. For a 100 user instance, what are the chances that a recent cache of All page 74 is available? Bots are crawling every page, and most pages are content from last month, last year, or 3 years ago.
I would expect Lemmy instances to have some limiters set for guest connections, especially for ones coming from datacenters. Like, it should be easy and senseful to only link and cache up to All page 10, or Hot page 5, and refuse guest loads of anything beyond that.
Ultimately this has been a recent-ish problem, and Lemmy simply doesn’t have this sort of function yet. It’s a goo thought, though.
As the other commenter said, bad bots are not easy to tell. OpenAI, Anthropic, etc identify themselves so are easier to block. They also tend to respect a robots.txt. The issue is the b=bots that don’t limit themselves, and route through hundreds of residential IPs. You literally see dozens of IPs all with approximately the same number of requests, like 80,000 per IP. If you block them they route through others. They seem to have an endless number of residential IPs to route through, presumably due to the things you see on Lemmy about the TV apps that proxy traffic even when the TV is off. I notice a lot via South American or South East Asian countries, which lead me to suspect at least some of these residential IPs are proxying through compromised devices that might not have up to date security patches available.
I dont believe it is that easy to tell if an IP is coming from a data center, unfortunately. To some extent you can tell its location with the geolocation database, but that is not authoritative and can be wrong or even contain intentional falsehoods. You can also see what is adjacent to it and make guesses that way, but that is often inconclusive due to common tunneling protocols like MPLS.
I believe the only remotely accurate way to tell if a connection is a bot is to use modules that detect bot behavior and redirect what it detects. Some users have even made infinitely recursive “traps” for bots that do not respect their robots.text file, which make their web page seem infinite so it scrapes forever over these fake pages that are less work to host than they are for the bot to parse through.
It is a very tough problem with few easy solutions. It will likely result in an arms race much like ads and ad blockers, hackers and firewalls, etc. It has so far, anyway.
The bad scraping bots are proxying their traffic via resiential IPs, so it doesn’t even matter. Presumably this is through the free TV apps that you see mentioned on Lemmy occasionally, or through compromised devices.