I shared a link from NPR Tiny Desk but there was no image preview or video embed. After investigating this I learned that when you do that, each instance picks up the link and individually retrieves the link preview nearly simultaneously. For gargantuan sites like YT or Reddit, this is a trivial amount of traffic and not a problem, but for smaller sites like NPR this results in a sort of botnet DDOS attack on the site’s servers. More here. Another example here . For that reason, NPR has blocked Fediverse servers like Mastodon.
I have experienced this on my personal server as well (DDOS), but at the time didn’t know why, exactly.
This isn’t the end of the world, but certainly is not great and hurts engagement with the content. Is there a solution for this? Perhaps using some sort of webtorrent service like PeerTube where they just fetch the information from another fediverse server instead of the source server? Maybe fetching embeds client-side? At least that would stagger the requests.
E: Many people have replied comparing this to the Reddit “hug of death” or “The Slashdot effect”. This is not the same at all. Those are legitimate site visits from humans that happen over the course of several hours. This is the result of several thousand servers all automatically fetching the same image simultaneously , and without any human involvement, and potentially next to zero human traffic to the site, which is why I compared it to a botnet or DDOS attack.
Sounds like every instance is doing the preview generation. Maybe it could grab the preview data it needs on the original instance, and pass that around with the post…
Well you can’t really trust the original instance to be truthful with its preview.
Same thing used to happen with reddit giving sites the hug of death lol
It’s unfortunate but kind of expected.
Its not at all the same thing
You’re right, it’s not like… thousands of network connections are happening to the same site in both cases resulting in resource exhaustion.
Oh, wait…
Having things in common does not make them the same thing. I explained this in the OP.
You’re right, neither of them are known for providing thousands and thousands of distributed network connections to the same destination resulting in that same destination server running out of resources. They’re clearly not the same thing at all, no, definitely not at all.
So we need people to just mass post links to bad websites, is what you’re saying.
i’m feeling less ambivalent about those reddit repost bots for a moment
Is there a reason why the publishing instance is not downloading the preview image, and then submits it with the post to the other instances? This way they would not have to fetch it themselves.
Yeah, thats how it should be: one download, everyone else downloads from that server, not the original source.
Seems abusable though
It is, but that’s what defederation is for: If there are instances that are being sketchy, they are supposed to get cut off from the rest of the Fediverse.
Seems abusable though
If one instance doesn’t trust another, they shouldn’t federate in the first place.
Seems abusable though
Exactly
Add metadata with a checksum of the og one with signature and let each client check that up.
If it’s a signed checksum then maybe. But if the og instance is doing the abusing then it won’t help.
Yeah there must be some trust indeed of the og instance. A scoring system could help with that.
Or … Or we could stagger the requests of the different instances so that they don’t overload the linked site. Why reinvent the wheel?
Eventually that leaves the load to the source event if it’s differed. And the load would still grow along the growth of the fediverse. So this would likely be pushing the issue to tomorrow. Signing content checksum isn’t exactly like reinventing a wheel, it’s something done in many contexts. And it removes the load from the source entirely.
Is this the same thing as the “Reddit hug of death”?
Similar, except those are caused by users visiting a link, whereas the Fediverse issue is federated servers gathering info before users even see a link.
How many servers are we talking about? 10,000 ?
Or being slashdotted.
Or the Digg Effect
it seems like ideally it shouldn’t attempt to preview the link before a user tries to view the content. i guess that would increase latency for users though
Sure would.
I have my blog address (which goes to my home server) in my Mastodon profile, and every time I post on Masto, my server gets a request from every Mastodon site that federates with my instance - i.e. hundreds of requests. It’s no problem for my server, because my blog is a static site, but for anything that dynamically generates every single page impression (like worpress or joomla), it could be a problem. Caching settings might help, I suppose.
Truth is, though, I get far more traffic from vulnerability scanners and AI crawlers that don’t honour robots.txt (or aren’t yet listed).
that don’t honour robots.txt (or aren’t yet listed).
Throw’em in the tar pit.
Limited mental capacity these days, so I don’t have the spoons to properly research and implement a solution at the moment. I installed Nepenthes last year, but I’ve never managed to get round to integrating it into my site. It’s low priority at the moment.
that don’t honour robots.txt
That’s essentially all of them in my experience.
At least anything “AI”
To be honest, if a website has no caching of their server-rendered parts, they are also doing something wrong! Very little sites really need to re-render a public page on every view.
Around 2010, I used to work at an MSP, and once had a customer that ran a custom LAMP stack website for local radio UK stations web presence. It was a bit slow, running on a dedicated physical server, but every time it snowed, the website would 500 out - because of too many requests to the “School Closures” page. The site had no caching other than Apache’s internal cache, but PHP pages could not be cached because “reasons”, and the original developer was “not available”. I optimised their MySQL indexes, increased the number of Apache workers, and it improved the render time per page and number of concurrent connections. Stress testing looked good.
Anyway, some months later, 2AM one snowy morning, I was on call, and it went down again. This was when I discovered the school closures problem. After diagnosing, and then liaising with the customer to discuss the options, I was told “just make it work”. I ended up modifying the PHP script to add some “on spec” caching that saved the HTML to a temp file in ramdisk, and only re-ran the query-and-render code if the cached copy was more than 5 minutes old. It was hacky, but it did the trick, and I was finished by about 4 AM. This hack was later applied at their request to a number of trouble-points in the source tree, as and when things broke.
We recommended adding a Varnish cache, and found a more generalised caching library but they wouldn’t/couldn’t authorise engineering work for this - they were running on a shoestring - and they already had the tech break-fix contract with us, and decided it was sufficient to just spot fix things as they broke rather than fix the root cause.
I left that MSP in 2012, so I don’t know what happened after that, but as far as I know, the site could still be running… unlikely, but possible.
Lemmy does this to itself, too - when you create a post it federates out and then every Lemmy instance that receives it makes a GET request to retrieve the post from the original server. Even though it just received the exact same data. Some other fedi software is even worse - Akkoma does a GET of the id of every activity it receives, not just for posts but for Likes too.
It’s insane.
Anyway, proper caching at the reverse proxy / Cloudflare level solves it. The same kind of caching setup would do the same for sites serving HTML, like NPR too.
That’s weird. Is that how it’s supposed to work, or did they just implement it in a bad way?
I’m not sure but my guess it’s an attempt to deal with the problem where sometimes federation activities arrive in the wrong order (especially after an instance has been offline for a while) - by making a GET to the origin server you can be sure you’ve got the latest version of the content. There are probably better ways to achieve that, though.
PieFed prioritises efficiency over correctness so it just accepts whatever is sent to it. In 3 years no one has complained about seeing stale content although I’m sure it happens occasionally.
I added a rule in my .htaccess for their user agents to direct all requests to a static page on my domain.
I mean, just how many instances are gonna ping the URL? Several hundred, low thousands at worst?
Unless it happens to be some very large media content or a dynamic page with no caching, I’d think the automated federation hits shouldn’t be too bad.
The influx of users that might come after a viral post though, that’s rough…
It’s just bad design. What happens when/if the fediverse scales up to many more instances?
I liked writing efficient code but every place I worked didn’t care at all about it. All they wanted was a finished feature and a kanban note moved to finished.
The many pointless presentations I’ve given about tech debt and code quality. Argued for redesigning poorly designed systems. They don’t care. Just churn out more features to cross off the list, and why do those features take so long?
Yeah I think a lot of us share this experience. All the stuff we are tought in our educations about clean code and architecture… Once we come out and work, management don’t want that stuff if it takes extra time. They want features shipped as soon as possible, and every meeting is about “how fast can you do this feature”.
And now of course embracing AI since it’s so fast. When things break, engineers will have to figure out the problem when the entire system is down, not management. :)
And then they can have a post mortem where they say that engineering must have better routines…lol.
I no longer work in tech but I quit at the top I think, before Ai was a requirement. And when consulting salaries was still good. Now they are awful.
It better fucking not
Yeah but we can’t say we want to encourage people to have/build/share independent smaller websites then beat them up when they are linked. That’s a huge mismatch of morality. Either we want to encourage people off the big platforms and should make it easier for the little guys or we are blowing magic smoke.
It’s obviously bad enough that major news orgs are blocking it.
Is that really why they’re blocking it I wonder…
It’s almost like the software that powers the internet was designed for a different time and is only still used because there’s monied interest in keeping it around. We need GNUnet.
is there something that makes this different to 17 other proposals for a new internet or is it just a case of
Or i2p.
Now this is interesting. Thanks for sharing
Oh wow GNUNet I havent heard of that in a while. How is it nowadays?
smaller sites like NPR
Norwalk Public Radio. From Norwalk, Iowa.
They can’t afford a $5 CDN?
For gargantuan sites like YT or Reddit
the people have spoken
Well they didn’t seem to have much to say?
smaller sites like NPR
Randomly stagger the times of each instance’s request.
+1-300 seconds
That’s basically what’s now implemented, iirc. At least in masto
300 seconds is a lot.
So linking my own website here is a bad idea? Glad I haven’t done that yet.
I don’t really get it. The image is federated, there’s no need for instances to refetch it. Just checked out some posts and indeed it’s there, in the
imageproperty. With the URL pointing to the Lemmy instance.So if this is actually an issue, that’s just bad programming and needs to be fixed.
Edit: didn’t notice OP uses Piefed. Unlike Lemmy and Mbin, it seems like Piefed doesn’t federate it.Edit: actually I’m blind, Piefed does federate it too, sorry piefed
The image is not federated.
I just took this random post from my frontpage: https://sh.itjust.works/post/68605733 and made a manual request for the federated JSON-LD.
{ "@context": [ "https://join-lemmy.org/context.json", "https://www.w3.org/ns/activitystreams" ], "type": "Page", "id": "https://sh.itjust.works/post/68605733", "attributedTo": "https://sh.itjust.works/u/derrickoswald", "to": [ "https://lemmy.world/c/technology", "https://www.w3.org/ns/activitystreams#Public" ], "name": "Stratospheric airship flew from US to Japan and back", "cc": [], "content": "<p>It seems with an unmanned airship they should be using hydrogen for the ~8% increased payload capacity.</p>\n", "mediaType": "text/html", "source": { "content": "It seems with an unmanned airship they should be using hydrogen for the ~8% increased payload capacity.", "mediaType": "text/markdown" }, "attachment": [ { "href": "https://arstechnica.com/gadgets/2026/10/trans-pacific-journey-tested-stratospheric-cell-tower-concept-in-japan/", "mediaType": "text/html; charset=utf-8", "type": "Link" } ], "image": { "type": "Image", "url": "https://sh.itjust.works/pictrs/image/df608ab3-b644-489d-b217-9224aa09e203.jpeg" }, "sensitive": false, "published": "2026-10-19T20:16:37.383385Z", "language": { "identifier": "en", "name": "English" }, "audience": "https://lemmy.world/c/technology", "tag": [ { "href": "https://sh.itjust.works/post/68605733", "name": "#technology", "type": "Hashtag" } ] }Notice the
"image": { "type": "Image", "url": "https://sh.itjust.works/pictrs/image/df608ab3-b644-489d-b217-9224aa09e203.jpeg" }Yes the image itself isn’t sent over (iirc they never are?), but it’s stored on sh.itjust.works. Other instances grab it from there, not the website the post links to.
I did notice just now though that some Lemmy instances seem to just proxy the image through their servers, which I assume is to avoid CORS. But that’s an instance choice, not a general fediverse issue.
Mbin does the same as Lemmy, but it also includes the image in the
attachmentproperty. Probably for compatibility with some other platform.One thing I didn’t notice before was that you’re using Piefed. That’s the one software I didn’t check before writing my previous comment. It does seem like Piefed is the outlier here. I tried a post from piefed.ca and the image is nowhere to be seen. Theimageproperty is not present, it’s not in theattachmentarray, and I can’t see any other property that contains it.Edit: A piefed.social post I just tried did have an image, so I assume I’m just blind.
Rimu posted a parent comment elsewhere regarding PieFed and Lemmy.
Are you sure? In your post you’re talking about fetching an image for a link preview, not an image post.
Usually, when I see an image post, the source is actually the pictrs of the source instance, so in that case I think it is federated.
No one was talking about an image post…
I figured a post with a link with preview image wouldn’t be the same in terms of event as an image post. Turns out it pretty much is, but also, I checked a few posts and cross-posts across instances, all of them have an image url of the original instance, not the one I’m viewing on. So if they are individually fetching this image, they’re not using it.
Edit: I was wrong, two of the crossposts just didn’t respond to the request for activity, so I was looking at the wrong response data
the image should be federated
Did I say “shouldn’t be”? Could have sworn i said “is”…
The image isn’t federated, but [I believe] it should be.
But I am already thinking it shouldn’t be because of hosting concerns.
