I shared a link from NPR Tiny Desk but there was no image preview or video embed. After investigating this I learned that when you do that, each instance picks up the link and individually retrieves the link preview nearly simultaneously. For gargantuan sites like YT or Reddit, this is a trivial amount of traffic and not a problem, but for smaller sites like NPR this results in a sort of botnet DDOS attack on the site’s servers. More here. Another example here . For that reason, NPR has blocked Fediverse servers like Mastodon.

I have experienced this on my personal server as well (DDOS), but at the time didn’t know why, exactly.

This isn’t the end of the world, but certainly is not great and hurts engagement with the content. Is there a solution for this? Perhaps using some sort of webtorrent service like PeerTube where they just fetch the information from another fediverse server instead of the source server? Maybe fetching embeds client-side? At least that would stagger the requests.

  • jaybone@lemmy.zip
    link
    fedilink
    English
    arrow-up
    128
    ·
    2 days ago

    That second solution is what I thought of as doing as I read this. It doesn’t rely on a third party service being up. And that instance has to do that work anyway. So why not just share the results with others?

      • 4am@lemmy.zip
        link
        fedilink
        English
        arrow-up
        120
        ·
        2 days ago

        The same way you know the rest of the data hasn’t been tampered with - you don’t. And when you find untrustworthy instances, you defederate from them.

        • SorteKanin@feddit.dk
          link
          fedilink
          English
          arrow-up
          17
          arrow-down
          1
          ·
          2 days ago

          That’s not true, you know the data hasn’t been tampered with because of HTTP signatures. The fediverse isn’t just “yolo, just trust me bro”. There are some parts that are a bit more towards that side (particularly with groups on Lemmy) but I don’t think this should be.

          • Natanael@infosec.pub
            link
            fedilink
            English
            arrow-up
            10
            ·
            edit-2
            1 day ago

            HTTP signatures are not a default feature, the baseline is ECDHE key exchange with forward secrecy and deniability. Headers are not typically signed.

            There isn’t even an official standard for redistributable signed page metadata. There’s just prototypes. I absolutely hope one of those prototypes becomes official, but we’re not there yet.

            The activitypub fediverse is literally very extremely Yolo trust me bro, it works because you can see the originating server with everything and misbehaving ones gets banned.

      • jaybone@lemmy.zip
        link
        fedilink
        English
        arrow-up
        48
        ·
        2 days ago

        I’m trusting the user who submitted the link and/or the instance that user is on. I’m doing that anyway by clicking on their link right?

      • rako@tarte.nuage-libre.fr
        link
        fedilink
        Français
        arrow-up
        4
        ·
        2 days ago

        So I receive a post from someone presumably with some comment, along with a preview of a link, and I’m supposed to trust one but not the other ?

    • khannie@lemmy.world
      link
      fedilink
      English
      arrow-up
      10
      ·
      2 days ago

      It was my first thought too but there are downsides to it. Trust is a small one given the nature of the system but compute and bandwidth costs could be an issue also, especially for larger instances.

      The first solution is more fragile but could be CDN’d and those are cheap.

      • Kangae_Hishiryo@scribe.disroot.org
        link
        fedilink
        English
        arrow-up
        5
        ·
        1 day ago

        WebTorrent kind of solution like PeerTube is the best, because it’s highly scalable yet not that resource-intensive, because everyone (even users) provides their bit; also, as it’s entirely P2P, it acts sort like a distributed and decentralized CDN, so it’s snappier for everyone because it’s more likely that you have a peer near to you like that.

        • khannie@lemmy.world
          link
          fedilink
          English
          arrow-up
          5
          ·
          1 day ago

          Absolutely LOVE this idea but I feel like a solid implementation would be a pain in the fanny (and it also requires other peers to be online). I dip in and out over the day myself but I don’t know what others use case is.

          Also it is far less trustworthy and harder to block bad actors (V’s removing a known bad actor from a relatively small peer group).

          • artyom@piefed.socialOP
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            9 hours ago

            Not really “peers” in this case, just different servers communicating amongst themselves instead of all going to the original source.

          • Kangae_Hishiryo@scribe.disroot.org
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 day ago

            Idk, the part of uptime of peers is solved precisely by the fact that not every peer will be connected at the same moments that every other peer. If I’m connected at 10pm, it’s highly likely that there will be at least another single peer at that hour that has what I’m pulling.

            As for bad actors, that’s something that at the end of the day is unavoidable. Though with some automated systems could be possible to make it more hard for them, but it’s not that different from a centralised approach, and thus is better because is computationally more efficient.

      • Ghoelian@piefed.social
        link
        fedilink
        English
        arrow-up
        6
        ·
        2 days ago

        I don’t think compute resources should be an issue, if anything it saves other instances resources.

        As far as I understand, right now, all instances are fetching this data individually, so they all have the same compute load from this. Doing it on one and sending it along with federation should keep resource useage pretty much the same on the originating instance, and less for all others.

        This would still increase bandwidth of course, but at least with all VPS providers I have used, bandwith is pretty cheap.