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.

you are viewing a single comment's thread
view the rest of the comments

[–] The_Decryptor@aussie.zone 14 points 1 week ago (1 children)

It's an access control method, called "authorized fetch". Rather than broadcasting the data you just announce the source of it, and then any client that wants to show it needs to negotiate with the originating server to request the data (And then blocklists and such come into play)

Say you've got 3 users, A, B, and C. A has blocked C, B follows A, and C follows B. Now A makes a post, B sees it in their feed and reboosts it, what does C see?

If B's server sends the full response along, then C can see the contents of A's post even though they've been blocked by A. But if all it sends is the URL of the post, C's server needs to make a request for it (providing authentication), and then A's server can reject it, so C sees nothing.

[–] Ghoelian@piefed.social 1 points 3 days ago

Okay, what you explained does make sense, but not in the context of a federation event (as far as I understand, which could very well be wrong).

If B’s server sends the full response along, then C can see the contents of A’s post even though they’ve been blocked by A.

Sure, but this would only be needed if a user needs permission or something to view a post. They don't, a post is (always, afaik?) public.

Besides, federation is not on a user level, but on an instance level. It doesn't matter if user A has blocked user B. As long as just one person on user A's instance does not have user B blocked, events and metadata will need to be federated. So, for public federated services, I don't think it makes any sense to use this kind of access control.