There’s another reason I don’t share “It’s FOSS” links anywhere: this should have been a github issue but it’s turned into a clickbaity headline. Every othe article coming out of “It’s FOSS” is either low effort, sensationalist, or both.
Please Don’t Share Our Links on Mastodon: Here’s Why! | itsfoss.com
Submitted 6 months ago by BuddyTheBeefalo@lemmy.ml to fediverse@lemmy.world
https://mastodon.social/@itsfoss/112364520275421073
Comments
halm@leminal.space 6 months ago
poplargrove@lemmy.world 6 months ago
The article mentions there are aleady a few issues, some quite old. The article is useful for raising awareness and hopefully getting the fix prioratized higher.
parpol@programming.dev 6 months ago
[deleted]CameronDev@programming.dev 6 months ago
I think they just advertised how trivial it would be to take their website down…
Hugh_Jeggs@lemm.ee 6 months ago
I always downvote posts with titles like this. Here’s Why -
TseseJuer@lemmy.world 6 months ago
same. read more to find out!
skullgiver@popplesburger.hilciferous.nl 6 months ago
[deleted]iltg@sh.itjust.works 6 months ago
thanks for saying this! i really don’t want to victim blame itsfoss for getting traffic spikes but if you cant handle ~20MB in one minute (~400kbps) of traffic you’re doing something really really wrong and you really should look into it, especially if you want to distribute content. crying “dont share our links on mastodon” also sounds like hunting windmills, block the mastodon UA and be done with it, or stop putting images in your link previews for mastodon, or drop link previews completely. a “100 mb DDOS” is laughable at best, nice amplification calculation but that’s still 100 megs
SatyrSack@lemmy.one 6 months ago
Direct link to article:
news.itsfoss.com/mastodon-link-problem/
TL;DR:
When you share a link on Mastodon, a link preview is generated for it, right?
With Mastodon being a federated platform (a part of the Fediverse), the request to generate a link preview is not generated by just one Mastodon instance. There are many instances connected to it who also initiate requests for the content almost immediately.
And, this “fediverse effect” increases the load on the website’s server in a big way.
Does Lemmy not cause this issue? Other federated software was not mentioned in the article at all.
catloaf@lemm.ee 6 months ago
So the preview should be federated as well?
How many requests are we actually talking about here, though? Is that better or worse than everyone clicking the link?
Max_P@lemmy.max-p.me 6 months ago
There’s some problem with a federated previews: tricking one instance into generating the wrong preview would spread to every instance. It’s been exploited for malware and scam campaigns in message apps.
rimu@piefed.social 6 months ago
2 requests per instance - one for the HTML of the page and another for a preview image.
chameleon@kbin.social 6 months ago
Lemmy (and Kbin for that matter) very much do the same thing for posts. I don't think they fetch URL previews for links in comments, but that doesn't matter: posts and comments are both fairly likely to end up spreading to Mastodon/etc anyway, so even comments will trigger this cascade.
Direct example: If you go to mastodon.social, stick
@fediverse@lemmy.worldin the search box at the topleft and click for the profile, you can end up browsing a large Mastodon server's view of this community, and your very link has a preview. (Unfortunately, links to federated communities just result in a redirect, so you have to navigate through Mastodon's UI.)BuddyTheBeefalo@lemmy.ml 6 months ago
In the comments on Mastodon, some say it’s like that everywhere in the fediverse.
deadsuperhero@lemmy.world 6 months ago
It’s an interesting and frustrating problem. I think there are three potential ways forward, but they’re both flawed:
-
Quasi-Centralization: a project like Mastodon or a vetted Non-Profit entity operates a high-concurrency server whose sole purpose is to cache link metadata and Images. Servers initially pull preview data from that, instead of the direct page.
-
We find a way to do this in some zero-trust peer-to-peer way, where multiple servers compare their copies of the same data. Whatever doesn’t match ends up not being used.
-
Servers cache link metadata and previews locally with a minimal amount of requests; any boost or reshare only reflects a proxied local preview of that link. Instead of doing this on a per-view or per-user basis, it’s simply per-instance.
I honestly think the third option might be the least destructive, even if it’s not as efficient as it could be.
Quacksalber@sh.itjust.works 6 months ago
As I understand it, 3) already happens. What causes the load is that each connected instance is also loading and caching the preview.
chiisana@lemmy.chiisana.net 6 months ago
Or 4) Ignore noise and do nothing; this is a case of user talking about things they don’t understand at best, or a blog intentionally misleading others to drum up traffic for themselves at worst. This is literally not a problem. Serving that kind of traffic can be done on a single server without any CDN and they’ve got a CDN already.
-
taanegl@lemmy.world 6 months ago
Gotta respect boycotting Cloudflare on principle… but also, why?
lvxferre@mander.xyz 6 months ago
That sounds a lot like a weird spin on the Slashdot effect, caused by content mirroring. It seems that it could be handled by tweaking the ActivityPub protocol to have one instance requesting to generate a link preview, and the other instances copying the link preview instead of sending their own requests.
But frankly? I think that the current way that ActivityPub works is outright silly. Here’s what it does currently:
- User is registered to instance A
- Since A federates with B, A mirrors content from B into A
- The backend is either specific to instance A (the site) or configured to use instance A (for a phone program)
- When the user interacts with content from B, actually it’s the mirrored version of content from B that is hosted in A
In my opinion a better approach would be:
- User is registered to instance A
- Since A federates with B, B accepts login credentials from A
- The backend is instance-agnostic, so it’s able to pull/send content from/to multiple instances at the same time
- When the user interacts with content from B, the backend retrieves content from B, and uses the user’s A credentials to send content to B
Now, here’s my question: why is the ActivityPub works in that way, instead of this one?
chicken@lemmy.dbzer0.com 6 months ago
Check out Nostr, ActivityPub alternative that does authentication separately from content, works more like that.
lvxferre@mander.xyz 6 months ago
I’m aware of Nostr. In my opinion it splits better this separation of back- and front-end tasks, even if it has a few problems on how relays work, depending on the demographic. It’s still an interesting counterpoint to ActivityPub.
DaGeek247@fedia.io 6 months ago
If server A makes one request, it keeps server B from being overload by thousands of requests from users A.
lvxferre@mander.xyz 6 months ago
“A” Users would need to send requests to some server anyway, either A or B; that’s only diverting the load from B to A, but it isn’t alleviating or even sharing it.
Another issue with the current way that ActivityPub works is foul content, that needs to be removed. Remember when some muppet posted CP in LW?
Tag365@lemmy.world 6 months ago
So why doesn’t a random follower posting a link on Mastodon cause server load issues, but a popular follower does?
cupcakezealot@lemmy.blahaj.zone 6 months ago
i mean it’s solid training but they do realise it’s not limited to mastodon, right?
the slashdot effect has been around for years
cbarrick@lemmy.world 6 months ago
Just put the site behind a cache, like Cloudflare, and set your cache control headers properly?
Max_P@lemmy.max-p.me 6 months ago
Even without Cloudflare, simple NGINX microcaching would help a ton there.
It’s a blog, it doesn’t need to regenerate a new page every single time for anonymous users. There’s no reason it shouldn’t be able to sustain 20k requests per second on a single server. Even a one second cache on the backend for anonymous users would help a ton there.
They have Cloudflare in front, the site should be up with the server being turned off entirely.
rimu@piefed.social 6 months ago
I've found that if left on default settings, CloudFlare is not that great at caching. It requires a bit of configuration to really make it sing. itsfoss.com _thought _ they were "using CloudFlare" but probably not to it's fullest potential.
helenslunch@feddit.nl 6 months ago
Thousands of instances simultaneously fetching link previews from a VPS w/2GB RAM.
cbarrick@lemmy.world 6 months ago
If caching is properly configured, the cache (Cloudflare) will see thousands of requests, but the VPS should only see one request.
tacofox@lemm.ee 6 months ago
This should be front and center, caching won’t be able to make up for that…