this post was submitted on 05 May 2024

53 points (87.3% liked)

Fediverse

28444 readers

825 users here now

A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).

If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!

Rules

Posts must be on topic.
Be respectful of others.
Cite the sources used for graphs and other statistics.
Follow the general Lemmy.world rules.

Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy

founded 1 year ago

MODERATORS

ruud@lemmy.world

Xylinna@lemmy.world

MrCenny@lemmy.world

TragicNotCute@lemmy.world

automodbeta@lemmy.world

woelkchen@lemmy.world

The Fediverse has a DDoS problem (aumetra.xyz)

submitted 6 months ago by punkyblob@lemmy.blahaj.zone to c/fediverse@lemmy.world

13 comments fedilink hide all child comments

I was recommended to share this article I wrote a few days ago on here, too; so here we are!

The TL;DR is "link embed fetching communes" as a partial "fix" to the issue (pretty buzzwordy, sorry for that)

all 17 comments

sorted by: hot top controversial new old

[–] Zak@lemmy.world 25 points 6 months ago (2 children)

The proposed solution of an intermediate server caching embeds is needlessly complex. The first server a link is posted to can fetch the embed, then push it out to every server receiving the post.

[+] skullgiver@popplesburger.hilciferous.nl 11 points 6 months ago* (last edited 6 months ago) (2 children)

[deleted]

[–] catloaf@lemm.ee 9 points 6 months ago (1 children)

The first server should be the one it was posted to. Then federate the embed just like the post itself.

If a server is malicious, it doesn't matter if that malice is transmitted in the post or in the embed, it should be defederated just the same.

[+] skullgiver@popplesburger.hilciferous.nl 3 points 6 months ago* (last edited 6 months ago) (1 children)

[deleted]

[–] Zak@lemmy.world 4 points 6 months ago (1 children)

In this case, generating fake excerpts is not something a user on a server controlled by someone else can do; they have to operate a malicious server themselves. Defederation is a good solution to malicious servers.

Certainly someone very determined could spin up a bunch of malicious servers and put out a bunch of posts containing fake excerpts, but they'd need followers to get any reach on the microblog side of the fediverse. They could spam Lemmy communities, but users would notice and downvote/report the posts.

So I think "just defederate" probably is an adequate solution here, at least as things currently sit. Were the fediverse to grow by an order of magnitude, I think it would need a reputation system to add a bit of friction to a brand new server or user getting a lot of reach quickly.

[–] rimu@piefed.social 3 points 6 months ago (1 children)

Not all servers are equal. I would trust a post from lemmy.world or lemmy.ml to have valid metadata, for example. It'd be great if admins had some way to specify trusted instances (with the biggest 6 instances as initial defaults).

There would be other uses for the trusted instances concept. Automatic sharing of moderation actions, block lists, community lists, etc

[–] skullgiver@popplesburger.hilciferous.nl 4 points 6 months ago* (last edited 6 months ago) (2 children)

[This comment has been deleted by an automated system]

[–] rimu@piefed.social 2 points 6 months ago

Link previews for content from untrusted instances could still be generated just as they are now.

The centralisation that has happened is a separate issue.

[–] Omniraptor@lemm.ee 1 points 6 months ago

It's not centralization if not everyone trusts the same server, which there is no obligation to

[–] punkyblob@lemmy.blahaj.zone 9 points 6 months ago

Actually an interesting point. My immediate concern with that idea is that it would open the door for disguising things for what they aren't. The solution was made from the general caution of not trusting remote servers regarding content they not necessarily control.

But yes, that would definitely be a solution, too.

[–] andyburke@fedia.io 16 points 6 months ago (1 children)

How is this not a caching issue on the linked server? Serving the same info up over and over from memory should be incredibly fast.

Are their pages dynamic and filled with ads and stuff or something that makes this a problem?

[–] chiisana@lemmy.chiisana.net 18 points 6 months ago* (last edited 6 months ago)

If you’ve skimmed over the original publication, it is actually worse: it is a non problem. Other users have pointed out already: ~100MB served over 5 minutes period is quite literally nothing for even one small VPS serving the content independently, let alone a site with CloudFlare in front like they claim to have.

[+] Carighan@lemmy.world -2 points 6 months ago (3 children)

[deleted]

[–] erlend_sh@lemmy.world 12 points 6 months ago* (last edited 6 months ago)

This is certainly not spam but rather a blog response, a time honored practice as old as blogging itself.

OP’s article links to the source article (albeit via its fedipost rather than its blog post; maybe best to link both) and contributes to the online discourse with a long form reply, detailing a possible solution.

Mischaracterizing such a clearly well-intentioned contribution as “blog spam” is disingenuous.

edit: thanks for retracting your comment. I hope my retort won’t dissuade you from continuing to engage in this community :)

[–] punkyblob@lemmy.blahaj.zone 11 points 6 months ago

How is this blog spam if it provides an approach on how to fix it (next to a recap)? I just put it on there because I collect stuff there.

But yeah, whatever, Lemmy is an interesting place.

[–] ThillyGooth@lemmy.world 8 points 6 months ago

This is not spam. The blog post discusses a current hot topic. There's no advertising on the site. OP has nothing to gain by sharing this. Don't make people hesitate to post quality content just because the topic has been discussed elsewhere.