The Fediverse has a DDoS problem | aumetra's Scribbles
aumetra.xyz
The Fediverse has a problem with accidentally DDoS-ing remote service. What can we do about it?

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)

  • @Zak@lemmy.worldEnglish
    25•7 months ago

    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.

      • @catloaf@lemm.eeEnglish
        9•7 months ago

        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.

          • @Zak@lemmy.worldEnglish
            4•7 months ago

            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
        3•7 months ago

        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

          • Rimu
            2•7 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.eeEnglish
            1•7 months ago

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

    • @punkyblob@lemmy.blahaj.zoneOPEnglish
      9•7 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.