Alex told you the foxes and boxes app got an update and it's actually good and you should update it.
You're very savvy about phones, so you know that updating things often breaks stuff or moves buttons around and makes you re-learn stuff that you already knew. You normally don't let things update at all, if they already work - but Alex is cool, so you let the fox thing update to the version that came out three weeks ago, from the version that came out eight months ago.
It all looks the same, but a thing pops up to tell you there's a new thing in the settings if you want to make a website out of your boxes.
Well that's kinda nifty. You poke around a bit and it asks you questions like
🦊 Do you have a web host? [yes] [recommend a good web host] [what's a web host]
And that all sounds like frankly too much of a pain in the arse so you close it. But then Alex messages you and says hey check out my website at alexandhislovelyshaft.com so you check it out on your laptop. It's all the stuff that was in his boxes, but instead of being in the app it's on a website, it's got fancy graphics and a search box and everything, it's a proper website.
So you message him back "WOW how'd you do that" and he's all "The badger did it" and you're all "Is it the same if the fox does it" and he's all "I dunno probably" and you're all "I will make some tea and sit down and try to understand this later on"
And later on you make some tea and set aside an hour - you tell yourself "No more than an hour, don't get sucked in, you know what you're like" - to figure this thing out. It only takes you ten minutes to figure out what the hell web hosting is, and then another five minutes to choose a free host, and five more minutes to copy your web host's login and password into the fox app (it was good about explaining WHICH login and password it wanted), and then two seconds to tap on "Make my boxes into a website and upload" and boom, website.
Then you forget the "just one hour" thing and you're up until 1am fiddling with the artwork and fonts and such. But that doesn't count because you got the site up pretty quick, this extra three hours was icing and decoration, you didn't spend three hours fiddling with servers you spent three hours on ART and that's always okay
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.
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.
@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.
^_^
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/
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.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.