• CosmicSploogeDrizzle
    link
    English
    910 months ago

    Honestly this is why I think fears of one instance growing too large are overblown. If Lemmy.ml pulls a reddit, then I’ll just move to beehaw. In fact I already have a lemmy.ml and a kbin.social account. I might make a beehaw anyway.

  • @Rhabuko@feddit.de
    link
    fedilink
    English
    710 months ago

    Another good thing is that you can completely separate/block instances from the others. We will thankfully never have to deal with something like T_D here.

    • @scoobford
      link
      English
      410 months ago

      We do have…something similar, but they are nice enough that I don’t think I’ve heard of them brigading.

      Which honestly…not that spreading propaganda and misinformation is a good thing, but as long as they don’t actively try to antagonize or disrupt other communities, I’m okay with them.

  • @cavemeat@beehaw.org
    link
    fedilink
    English
    610 months ago

    I really like the fediverse for this, its such a smart and user-oriented concept (admittedly, I wasn’t around in the early web when this kind of setup was more common).

    • @argv_minus_one@beehaw.org
      link
      fedilink
      English
      710 months ago

      This wasn’t particularly common on the early web. There were a multitude of websites, but they were connected only by hyperlinks. There were few if any groups of websites that replicated each other’s content, as with the Fediverse.

      It was, however, common with some non-web protocols. Most notably, Usenet and email have always been federated, though with very different goals than the Fediverse: not to resist centralized corporate control, but because connectivity to other servers wasn’t always online. Instead, you’d read and write your Usenet posts and emails on a nearby server, often at the university or business campus where you study or work, using your terminal or microcomputer. The server would then periodically call other servers with a dial-up modem, exchange all pending messages with a batch transfer protocol like UUCP, and then hang up until next time. Messages often had to be forwarded several times before finally reaching the intended recipient. This store-and-forward network was painfully slow by modern standards, but it was by definition federated. You could send and receive emails and Usenet posts even while your site was offline, and although others would not see your messages right away, they would see them eventually.

      The Internet, by contrast, is ludicrously fast and always (well, almost always) online, so this sort of need no longer exists. Large websites still do use multiple servers scattered around the world in order to balance load, but unlike the UUCP system of old, it’s transparent to the end user. When you try to use such a website, a nearby server is automatically chosen for you by the network itself; this is called anycast routing.

      Unfortunately, anycast routing has made it feasible for one company to control the entire network and use it toward nefarious ends, and now the old idea of federation has re-emerged as a solution to this new problem.