this post was submitted on 08 Sep 2024
100 points (94.6% liked)

Fediverse

28398 readers
497 users here now

A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).

If you wanted to get help with moderating your own community then head over to [email protected]!

Rules

Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy

founded 1 year ago
MODERATORS
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 10 points 2 months ago (3 children)

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

[–] [email protected] 14 points 2 months ago* (last edited 2 months ago) (1 children)

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?

[–] [email protected] 2 points 2 months ago (1 children)

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

[–] [email protected] 2 points 2 months ago

@Blaze @ada @fediverse There is a small number of personal PDSes, plus Bridgy's one: https://blue.mackuba.eu/directory/pdses, but right now there aren't really any public open-signup ones, because they're limiting them to 10 users per PDS in this phase (I mean you can create more, but they won't be seen by the Bluesky relay). They implied that the network/software is not yet ready for this yet at this point, because a lot of things are still in flux (e.g. they're adding OAuth now).

[–] [email protected] 8 points 2 months ago* (last edited 2 months ago) (2 children)

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.

[–] [email protected] 6 points 2 months ago

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

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

[–] [email protected] 1 points 2 months ago

@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.

[–] [email protected] 8 points 2 months 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...