Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> That is good, but it's still a centralized source of truth.

It's not. It's a trustless aggregator. The PDSes are the sources of truth, and you can crawl them directly. The relay is just an optimization.

> Messages aren't broadcast through a central firehose

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 does perfectly without the need of any bulky machine or node acting as a relay for the rest of the network

ActivityPub doesn't do large scale aggregated views of the activity. The peer-wise exchanges means that views get localized; this is why there's not network-wide search, metrics, or algorithms.

> This is why ActivityPub has a discovery problem by the way,

right

> but it's just a symptom of real federation.

"real" ?



>The PDSes are the sources of truth, and you can crawl them directly. The relay is just an optimization.

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.


> Let me ask you this, is it possible for me to connect to a PDS directly, right now, via the bluesky app?

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.


> If you open devtools you'll see that the app is communicating with your PDS.

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?


> You can't truly be federated if you require centralization.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: