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?

[–] chicken@lemmy.dbzer0.com 3 points 6 months ago (1 children)

Check out Nostr, ActivityPub alternative that does authentication separately from content, works more like that.

[–] lvxferre@mander.xyz 3 points 6 months ago* (last edited 6 months ago)

I'm aware of Nostr. In my opinion it splits better back- and front-end tasks than the AP does, even if the later does some things better (as the balance between safeness and censorship-resistance). It's still an interesting counterpoint to ActivityPub.

load more comments (6 replies)