If I understand correctly it doesn’t matter where the user’s profile is hosted, the point is the user has a store of data that can be accessed by multiple apps via the AT protocol, only naming convention separates one app’s data from another’s within a given user’s profile.
Yeah I understood that part, was just confused by this particular sentence
Re:Open Social
by steveklabnik on Saturday September 27, 2025 @01:09PM
(#45397553)
The “Bluesky API” is the appview, but the avatar is stored in your PDS. Even if you’re using a PDS hosted by Bluesky, it’s a different component that’s being asked to serve the avatar.
Interesting. Ok just saw this https://github.com/bluesky-social/pds
> Self-hosting a Bluesky PDS means running your own Personal Data Server that is capable of federating with the wider ATProto network.
So pds (personal data server) is like the container where you chose to store the data and it follows a certain standard.
If the container is hosted is bluesky, i still consider it a "bluesky api" but I understand the nuance better now.
I think I understand the theory. But in fact it looks like tangled.sh is indeed using a "proprietary" Bluesky API rather than... e.g. calling `danabra.mov` right away to fetch his avatar: https://tangled.org/@tangled.org/core/blob/master/avatar/src...
... or am I misunderstanding?
Question:
> What’s more interesting is that Tangled prefilled my avatar based on my Bluesky profile. It didn’t need to hit the Bluesky API to do that; it just read the Bluesky profile record in my repository.
I'm a bit confused by this. If a bluesky avatar contains an image, isn't that stored (at least by default) within bluesky? Meaning that Tangled will have to hit the Bluesky API?
Or maybe Dan is saying that his own repository is not hosted with Bluesky in which it would make sense, if wherever his repo is stored is getting hit to retrieve the image.