Untitled attachment

Notices where this attachment appears

1. Embed this notice
   Alyx (alyx@eldritch.cafe)'s status on Tuesday, 17-Sep-2024 17:40:34 JST Alyx

   So, 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.

2. Embed this notice
   CoffeeGeek (coffeegeek@flipboard.social)'s status on Tuesday, 27-Aug-2024 07:55:58 JST CoffeeGeek

   in reply to

   Actually, I can still post content links here to CoffeeGeek, but I have to be smart about it: I have to post them as links, and also attach a photo to my post, so that the link doesn't trigger a card call to our website.

   So, going forward (for now at least), when we do post new content on CoffeeGeek, I will post the link here, but also attach a photo related to the story. The link should still work, but not bombard our website from 1000s of instances looking for a card.

3. Embed this notice
   Yohan Yukiya Seseㆍ사요한・謝雪矢 (youronlyone@c.im)'s status on Monday, 15-Jan-2024 01:55:32 JST Yohan Yukiya Seseㆍ사요한・謝雪矢

   in reply to

   @codeinabox It's different.

   Webmention is similar to #pingback that was popular with blogs and websites.

   Webmention basically sends information to the sites linked that hey, I mentioned your link in my website.

   So, if a third-party site is using OSM (as an example) materials but did not include any link back to them, webmention won't be triggered.

   Also, one can trigger webmention without actually having a visible link. So, in this case, providing Attribution, since there is no visible link, there still is no Attribution given.

   ^_^

   @openstreetmap

4. Embed this notice
   Bø!rge (forteller@tutoteket.no)'s status on Tuesday, 18-Jul-2023 04:49:18 JST Bø!rge

   Seeing if I'm able to install @Castopod on my DreamHost shared hosting. Using this guide, since I couldn't find info about it on the Castopod website.

   So far the most annoying thing is the time it takes to upload the files to the SFTP… But normally I don't upload much stuff, so I haven't put any money into fast upload speeds.

   https://mariolurig.com/coding/install-castopod-shared-hosting/

5. Embed this notice
   FediTips has moved! (feditips@mstdn.social)'s status on Monday, 31-Oct-2022 20:12:37 JST FediTips has moved!

   in reply to

   @IgnisIncendio

   The only forum-like part of a server is its Local timeline. It's the only thing that requires you to be on that server or looking at that server's website.

   So, whether you regard a server as a forum depends on whether you use the Local timeline or not.

   I personally don't use Local much, so to me the Fediverse is entirely cross-server.

   But if someone does use Local a lot then they might feel differently.

6. Embed this notice
   FediTips has moved! (feditips@mstdn.social)'s status on Monday, 31-Oct-2022 01:42:29 JST FediTips has moved!

   in reply to

   @The_Colbobs

   Your server's website is the site you signed up on. If you don't remember, look at the address on your profile page, it's underneath your name (looks like @ user @ server).

   The last part of your address is your server's website.

   So, for example, looking at your profile I can see you're on https://mstdn.social