• @Sl00k
    link
    English
    12
    edit-2
    20 hours ago

    Tbf a lot of the arguments against their federation capabilities here is that they make it hard to access, which is a much smarter decision from a user experience perspective. Majority of the general public has absolutely zero idea wtf federation and instances means and that’s okay, they just need a quick way to sign up and get using the platform.

    Considering you can host your own PDS and Relay I would consider that close enough to federation that it should be included in fediverse discussions and shouldn’t splinter.

    The big architectural difference is instead of AP federation with each instance it’s just one massive firehouse on the protocol (federation with all default) which absolutely has its benefits compared to ActivityPub.

    • @[email protected]
      link
      fedilink
      English
      415 hours ago

      The fact that there is still to this date no alternative Bluesky server that can be used to register seems to indicate that they put the entry cost to federation too high.

      If the federation is only theoretical and never happens in reality, it’s not really federated.

      • @Sl00k
        link
        English
        1
        edit-2
        5 hours ago

        The fact that there is still to this date no alternative Bluesky server

        This is true, but why would someone go out of their way to do this when all data ends up in the same firehose?

        Three circumstances:

        • Domain name federation: Currently live and implemented across the site, in fact I’ve done this.

        • PDS (personal data) federation: You would ideally only host your own PDS to host your own data.

        • Backup: You want to host a backup of all Firehose data for access by others (very valid case, but you’re paying to just host data that’s already available)

        Any other circumstance it’s going to cost the host money for effectively no usecase. Sure people can do it but why would the host pay hosting fees? If Bluesky went down a path of introducing advertisements or became a pile of shit then there’s true incentive to host your own independent PDS/Relay/App View. I generally think people just aren’t understanding federation across Bluesky because it truly is a lot more complicated complicated than ActivityPub (some pros / some cons).

        • @[email protected]
          link
          fedilink
          English
          14 hours ago

          Sure people can do it but why would the host pay hosting fees?

          Fediverse admins pay fees for their instances. BlueSky requiring such high fees to run your own instance seems just a hidden way to prevent people from actually creating federated instances.

          If Bluesky went down a path of introducing advertisements or became a pile of shit then there’s true incentive to host your own independent PDS/Relay/App View.

          So if tomorrow Elon Musk buys BlueSky, the only alternative for people to keep using the AT Protocol and stay federated with BlueSky without being under Musk’s control would be to be running that very expensive relay?

          • @Sl00k
            link
            English
            13 hours ago

            Fediverse admins pay fees for their instances.

            Yes but they have communities within their instance. With ATProto everything is published to the protocol so there’s no inherent internal community, the instance is just the infrastructure at that point, not a community.

            Also in terms of expense I’ve seen it’s around $250 / month which equivalent to larger Lemmy instances, I think programming dev was around this price point so it’s not absurdly large. But it is at the point of why run this if I’m just hosting infrastructure and not creating a community.

            I have been reading that some people are working on subdomain @'s (equivalent to Lemmy username@domain) within ATProto, which leads to more community interaction, but I think that’s still handled under the Domain federation not the PDS / Relay federation.

            • flamingos-cantM
              link
              fedilink
              English
              21 hour ago

              Also in terms of expense I’ve seen it’s around $250 / month which equivalent to larger Lemmy instances, I think programming dev was around this price point so it’s not absurdly large.

              I don’t know about prog dev, but Lemmy instances are fairly cheap to run, see this thread https://lemmy.world/post/19466047.

              And to give my potential hot take, but I think what Bluesky and the AT protocol does should be called crawling instead of federating. If I understand things correctly, then what AT expects is for a replay to crawl the network looking for relevant data in PDSs, as opposed to APub where you push your data to the relevant places. I know this is semantics, but if we accept the Bluesky definition of federation then Google and Bing are federation services and that just doesn’t feel right.

              • @Sl00k
                link
                English
                127 minutes ago

                And to give my potential hot take, but I think what Bluesky and the AT protocol does should be called crawling instead of federating

                Yeah I definitely wouldn’t argue against it, throwing my hot take out, I would say we should call all of these platforms decentralized social media instead of tying everything to federated social media, and keep everything under the same umbrella. But obviously crypto has somewhat degraded the word decentralized 😅.

            • @[email protected]
              link
              fedilink
              English
              21 hour ago

              Yes but they have communities within their instance. With ATProto everything is published to the protocol so there’s no inherent internal community, the instance is just the infrastructure at that point, not a community.

              Ah, thank you for this. Indeed paying for infrastructure without any real community feeling isn’t really attractive.