Trying to figure this out as in the recent threads a few people said that Bluesky was federated, but it didn’t seem to actually be the case.

https://bsky.social/about/blog/02-22-2024-open-social-web in February announced that Bluesky would allow federated servers

The Bluesky documentation on the topic isn’t very clear. They mention Bluesky.social a lot, as if it’s supposed to be the one central server other PDS need to federate with:

Bluesky runs many PDSs. Each PDS runs as a completely separate service in the network with its own identity. They federate with the rest of the network in the exact same manner that a non-Bluesky PDS would. These PDSs have hostnames such as morel.us-east.host.bsky.network.

However, the user-facing concept for Bluesky’s “PDS Service” is simply bsky.social. This is reflected in the provided subdomain that users on a Bluesky PDS have access to (i.e. their default handle suffix), as well as the hostname that they may provide at login in order to route their login request to the correct service. A user should not be expected to understand or remember the specific host that their account is on.

To enable this, we introduced a PDS Entryway service. This service is used to orchestrate account management across Bluesky PDSs and to provide an interface for interacting with bsky.social accounts.

https://docs.bsky.app/docs/advanced-guides/entryway#account-management

Self-hosting a Bluesky PDS means running your own Personal Data Server that is capable of federating with the wider Bluesky social network.

https://github.com/bluesky-social/pds?tab=readme-ov-file#what-is-the-current-status-of-federation

The custom domain name is still something else, and does not seem to require a PDS: https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial

So, to come back to the title question, do people know of an example of PDS that can be used to access Bluesky without being on the main server?

  • BlazeOP
    link
    fedilink
    English
    arrow-up
    10
    ·
    9 days ago

    Indeed, but I’m a bit surprised there isn’t any list of alternatives servers.

    I would have to look more into the protocol specification, but it seems like this isn’t really federation, alternative servers are still relying on the central server, and that’s why nobody bothers with setting one up

    • Ada@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      13
      ·
      edit-2
      9 days ago

      Why would someone host a server and pay for it out of their own pocket, when the protocol just turns in to an invisible piece of infrastructure that people don’t even know exists?

      AP instances allow for communities and identity to build around them, so there is a non monetary incentive to running them, but what’s the incentive to run an equivalent on bluesky and make it public?

      • BlazeOP
        link
        fedilink
        English
        arrow-up
        2
        ·
        8 days ago

        Definitely, that’s why I guess there are still no other server than Bluesky’s

    • poVoq@slrpnk.net
      link
      fedilink
      English
      arrow-up
      8
      ·
      9 days ago

      There are some people hosting their own identity server, but yes the centralisation of the main aggregator server seems to be by design as they even scare people away from trying by talking about the high resource requirements of doing so.

      IMHO Bluesky is only federated in the sense that responsibility for content and moderation can be outsourced, but the user endpoint stays mostly in control of Bluesky. This makes a lot of sense if you think about it from a company perspective… outsource the legally and personnel critical parts and keep the ones that are lucrarive for advertisement and can be easily scaled by throwing hardware at it.

      But you must be a real sucker to take them up on that very one sided offer…

    • hoshikarakitaridia@lemmy.world
      link
      fedilink
      English
      arrow-up
      8
      ·
      edit-2
      9 days ago

      That sounds like a really dumb design idea. Why make a federating protocol if you still rely on the server? I don’t even get why they did it at all then.

      That’s indeed very interesting and peculiar.

      • @hoshikarakitaridia @Blaze @fediverse I think the main reason is that this solves a lot of UX problems that Fedi has because of its architecture, things like:

        - thread comments, like counts, follower lists not being consistent between instances
        - not being able to easily interact with content that’s not already cached on your instance
        - user/post search not working globally, for the same reason

        On Bluesky, the AppView indexes all that, and you load threads, feeds and do search through there.

      • BlazeOP
        link
        fedilink
        English
        arrow-up
        8
        arrow-down
        1
        ·
        9 days ago

        They could pretend to be federated while they’re not.

        Might show them in a more positive light to the general public