Well, yes, that's what you do when you log in. If you open devtools you'll see that the app is communicating with your PDS.
> So are relays really just an optimization or an integral part of how ATProtocol is supposed to work?
I think the issue here is that you're mentally slicing the stack in a different way that atproto does. You expect each node the be a full instance of the application, and that the network gets partitioned by a bunch of applications exchanging peerwise.
A better mental model of atproto is that it's a network of cross-org microservices. https://atproto.com/articles/atproto-for-distsys-engineers gives a decent intuition about it.
That's pretty cool. Does bsky.app do a DID resolve or does it have a faster back channel for determining PDS addresses for bsky.social?
I’m not so sure: isn’t the certificate transparency log a pretty good example of a federated group of disparate members successfully sharing a view of the world?
That requires some form of centralization to be useful (else it’s not really a log, more of a series of disconnected scribbles), and it’s definitely a true federated network.
This is such a massive understatement. the relay is the single most important piece in the entire Bluesky stack.
Let me ask you this, is it possible for me to connect to a PDS directly, right now, via the bluesky app? or is this something that will be possible in the future?
>ATProto works like the web does. People publish information on their servers, and then relays crawl them and emit their crawl through a firehose.
>ActivityPub doesn't do large scale aggregated views of the activity.
So are relays really just an optimization or an integral part of how ATProtocol is supposed to work? ActivityPub doesn't require relays to function properly. This is why I say it's real federation. You can't truly be federated if you require centralization.