Some people have this bad habit of talking about stuff they don't understand....

Just had a BlueSky user claim that they have ATproto PDS hosted that doesn't talk to BlueSky servers....so I logged into my BlueSky profile on the BlueSky servers and found their account...

It definitely connects to BlueSky servers....‍️

@BeAware I think the misunderstanding is because you're looking at it from the ActivityPub perspective and expect it to work in a similar way, but it doesn't, but that doesn't mean that it's worse.

You're asking about connecting to Bluesky servers, but there's really two different things here that I think are worth separating:

1) when I have my PDS, do I need to contact any Bluesky servers in order to communicate with someone else who has a PDS?

2) do our posts end up on Bluesky servers?

@BeAware By looking up the account on bsky.app you prove 2), but not 1).

What do you need to communicate with someone: you make records like follow, like, comment to your PDS. You don't need Bluesky servers for that.

But you also need to read their replies in notifications/threads/timeline and the posts they make in a feed. For that you need an AppView you can pull this data from. Right now only Bluesky runs an AppView.

@BeAware But like I mentioned in the other thread, I could build some bare-bones minimal AppView that does these things with not that much more work on top of what I have now, and then I could at least follow and reply to someone and read their responses. Mostly I'm missing follows data at the moment, if we ignore likes, I have the posts.

@BeAware An unrelated question is whether our posts end up on Bluesky servers. By default yes unless you try hard to stop that, I'm not sure how much that is possible. Relays generally can crawl the network and discover PDSes to pull from, so you'd need to have an IP whitelist and block connections from other IPs, but theoretically possible. Otherwise your profile and posts will be visible on bsky.app - even if you have your own PDS and use your own AppView, but that's ok. Just another copy.

@mackuba that's all cool and helps me really understand how it all works!

Though, the last part is the one most people here would be concerned about, I'm sure. Fediverse is *really* nitpicky about their data, as I'm sure you know.

@BeAware Oh yeah, I know very well. One of the reasons why I build stuff for AT and not for AP

That is a bit of a fundamental difference, so if someone *really* cares about this, they're probably better off sticking to AP (and not enabling Bridgy), because that's not likely to change in a major way because the whole architecture is built on this.

@BeAware E.g. the reason why I can generate a chart like this on my own website is because I have all those bridged posts in my SQLite, so I can do something like "select count(*) from posts group by origin, date".

@mackuba I'm on the side of wanting my data in as many places as possible, but under my direct control, accessible via my own website, so right now Fedi/AP continues to be one of the only places to do that. When that changes and there's a easily deployable web view where I can finely tune who has access as well, I'll probably look into deploying something and messing around.

@BeAware Technically [public] AP posts also end up having their copies on a ton of different servers though, right?

@mackuba yeah, a TON, like 20-30,000 all owned by different groups of people. Not just one owned by a company. The limited amount of servers is also an issue along with the no webview on my own website, like Mastodon, Akkoma, Misskey, etc.