Just put the site behind a cache, like Cloudflare, and set your cache control headers properly?

They mention that they are already using Cloudflare. I’m confused about what is actually causing the load. They don’t mention any technical details, but it does kinda sound like their cache control headers are not set properly. I’m too lazy to check for myself though…

I always downvote posts with titles like this. Here’s Why -

So why doesn’t a random follower posting a link on Mastodon cause server load issues, but a popular follower does?

deleted by creator

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

Note that the second way would not create this “automated Slashdot effect” - only A would be pulling info from the site, and then users (regardless of their instance) would pull it from A.

Now, here’s my question: why does the ActivityPub work like in that first way, instead of this second one?

It’s an interesting and frustrating problem. I think there are three potential ways forward, but they’re both flawed:

1. 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.

2. 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.

3. 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.

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.