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.
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?
You're viewing a single thread.
66 comments
So, from up close it seems like people can have their own servers (i checked wurzelmann.at which is currently on the frontpage) but they do not seem to have their own frontend.
This indeed makes it so that for people to actually SEE your content you must federate with one entity and are controlled by them.
Imo this is very bad because it takes the freedom out of federation. Yes, you dont need to login to an app but if they ban you or defederate or delete your post, nobody will see it, right?
Please someone who has tried and gets the technical details shed light on this.
Their app is open source, but it doesn't give any instructions on how to self-host it, in fact it seems to not have been designed with self-hosting in mind given the forking section of the ReadMe:
You have our blessing 🪄✨ to fork this application! However, it's very important to be clear to users when you're giving them a fork.
Please be sure to:
Change all branding in the repository and UI to clearly differentiate from Bluesky.
Change any support links (feedback, email, terms of service, etc) to your own systems.
Replace any analytics or error-collection systems with your own so we don't get super confused.
The impression I get from Bluesky is that it doesn't view federation as a core feature of its platform, just a nice technical oddity. I'm no expert on the AT protocol, but from a quick skim of the quickstart, their view of federation seems to be having disparate data repositories (Personal Data Servers) app developers can put their app data into. It doesn't really seems to be about different software communicating with each other.
In contrast, ActivityPub is about passing JSON between servers in a somewhat standard format so different software can reasonably understand what that JSON represents and act on it in a way that makes sense for that software.
(But again, I'm don't know anything about the AT protocol, I could be completely wrong here)
Thanks for chiming in. Thats very insightful. It still seems like bsky is claiming to be something that its not.
@hauilemmy@Blaze Yeah, it's very centralized at the moment. The idea of AT is that you can host your own Relay as well as PDS, so if I didn't like Bluesky I could make Nate's relay and have my relay pull the posts from the PDSs of the people I follow and sidestep Bluesky entirely. Though Bluesky was only opened up very recently so Bluesky is the only relay I know of ATM.
Some (maybe most) of these accounts are likely using custom domain linking instead of a server.