Like many, when the recent defederation went down, I decided to create a couple other logins and see what the wider fediverse has had to say about it.

I’ve been, honestly, a bit surprised by the response. A huge portion of people seem to be misidentifying communities as belonging to “lemmy” as opposed to the instances that host them. I think a big portion of this seems to be a fundamental misunderstanding of what this software is, and how it works.

For example, lemmy.world users are pissed at being de-federated because it excludes them from Beehaw communities. This outrage seems wholly placed in the concept that Beehaw’s communities are “owned” by the wider fediverse. This is blatantly not how lemmy works. Each instance hosts a copy of federated instances’ content for their users to peruse. The host (Beehaw in this example) remains being the source of truth for these communities. As the source of truth, Beehaw “owns” the affected communities, and it seems people have not realized that.

This also has wider implications for why one might want to de-federate with a wider array of instances. Lets say I have a server in a location that legally prohibits a certain type of pornography. If my users subscribe to other instances/communities that allow that illegal pornography, I (the server admin) may find myself in legal jeopardy because my instance now holds a copy of that content for my users.

Please keep this in mind as you enjoy your time using Lemmy. The decisions that you make affect the wider instance. As you travel the fediverse, please do so with the understanding that your interactions reflect this instance. More than anything, how can we spread this knowledge to a wider audience? How can we make the fediverse and how it works less confusing to people who aren’t going to read technical documentation?

  • unknowing8343
    link
    fedilink
    English
    arrow-up
    7
    ·
    2 years ago

    Instances hold copies of other instances’ communities? I thought it was simply an API call to the other server. Not an expert, tho.

    • TheOneCurly@lemmy.theonecurly.page
      link
      fedilink
      English
      arrow-up
      10
      ·
      2 years ago

      Yep, on regular intervals your instance asks for the latest data from the remote community and that’s what it serves to its users. So it doesn’t matter if 1 person or 100 are subbed on asingle remote, it’s the same number of calls.

      • unknowing8343
        link
        fedilink
        English
        arrow-up
        3
        ·
        2 years ago

        Is there a reason for working like this and not simply be a portal to the other instance’s community?

        • cnnrduncan@beehaw.org
          link
          fedilink
          English
          arrow-up
          7
          ·
          2 years ago

          I’m not a lemmy dev but my understanding is that doing it that way would end up exponentially increasing latency once you start getting nested links to communities - accessing a post on lemmy.world that was linked to lemmy.nz and then finally read through a beehaw account, for example, might have to jump through at three servers on opposite sides of the world before getting to me rather than just being served directly across the pacific from beehaw’s server to me!

        • ‘Leigh 🏳️‍⚧️@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          2
          ·
          2 years ago

          Probably for reliability and stability — otherwise, every view from every federated instance would create a new request to the hosting instance. The protocol itself would basically DDoS smaller instances. Also you can still read the cached version on your home instance if the remote instance is temporarily down.

    • Cipher@beehaw.orgOP
      link
      fedilink
      English
      arrow-up
      9
      ·
      edit-2
      2 years ago

      That is correct, and this is why a new instance only shows the most recent 20 posts for a community until someone from the viewing instance subscribes to it. From that moment forward (barring de-federation), the host instance sends updates to the viewing instance. The viewing instance provides content to its users from the local copy that it stores.