Lots of normal traffic is instant. Throttling must be handled by for in this instance NPR or its providers routers because even if hammering is a bad practice, we are participating in why it happens at all if we just build structures to mitigate it.

Yes that’s why I included a solution, and explained explicitly that it can be solved but only temporarily

How many servers are we talking about? 10,000 ?

Or the Digg Effect

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.

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.

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.

At least anything “AI”

GNUnet provides privacy-by design

Money doesn’t want us to have privacy.

Tl;dr: Lemmy and Mbin attach an image, Piefed seems not to. Though some Lemmy instances seem to only proxy the image, not host anything themselves.

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 attachment property. 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. The image property is not present, it's not in the attachment array, and I can't see any other property that contains it.

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.

the image should be federated

Is that really why they’re blocking it I wonder…

It better fucking not

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.