AlyxSo, I fell down a rabbit hole. I learned that Mastodon can "DDoS" a server as thousands of instances fetch the metadata of a URL.
Interestingly, this issue on Mastodon is also challenging Bluesky.
The post that started all of this is: https://aumetra.xyz/posts/the-fedi-ddos-problem. Thanks to @aumetra for writing it! Give it a read first; it provides some context.
My understanding (I'm stoopid, so don't quote me):
On Mastodon's end, the issue remains unsolved. Their stance is essentially: trust your instance to fetch the correct metadata. Yes, this approach can cause a traffic surge, but there's no better solution at the moment. Relying on clients would exacerbate the issue.
One potential solution could involve relays to centralize the fetching operation, offloading this task to a network of relays. This would centralize things a bit more while keeping options open: any instance could choose to use a relay or not. This would mitigate the issue, but not completely solve it.
On the AT / Bluesky side, when you create a post (using their lexicon "app.bsky.feed.post"), you can pass any metadata you want (https://docs.bsky.app/docs/advanced-guides/posts#website-card-embeds). Their stance is that if someone does something misleading, it will be reported.
Explanation of the “attack”: https://www.bentasker.co.uk/posts/blog/security/bluesky-posting-enables-misinformation-and-phishing-campaigns.html
Related discussion: https://github.com/bluesky-social/atproto/discussions/1304
At the end of the day, you have to trust someone anyway: your Mastodon instance, your Mastodon/Bluesky client, the author of the post, or a centralized endpoint serving the metadata for you.
@renchap wrote about this, offering various ideas to solve this: https://gist.github.com/renchap/3ae0df45b7b4534f98a8055d91d52186
If I can offer my humble opinion after gathering some information on the issue (again, I'm stoopid), the best approach is to rely on the website. It's the source of everything.
First, having a cache in front of websites (like a CDN or reverse proxy) would prevent this issue entirely. But that's more of a workaround than a real solution. But like it's 2024... Come on.
Second, signing the metadata is a great idea as well, and it would again rely on the website as the source of truth.
However, another problem remains unsolved: what if someone maliciously publishes a post with tampered metadata? It would get federated as is.
So having a signature on the website's end would solve both problems: you can check the signature, and if it doesn't match, then fetch the metadata yourself. If it matches, you can simply republish it without further verification, and so, not hammering the website.
So my opinion is: trust the website first, then use a relay to balance the load, and finally rely on your own instance, just as it is today.
Give me your thoughts! I fell into a rabbit hole with this post, and I love how complex the issue is to solve.
Schnouki
Lord
All GNU social JP content and data are available under the