Recent searches
Search options
One startling thing about the #ATProtocol is that it's index-centric by design, which requires all user content to be public. As @charlesdardaman figured out in mid-April, zero authentication is needed to see everything happen in real time. https://github.com/CharlesDardaman/blueskyfirehose
So, if you didn't score an invite last week + are suffering from FOMO, you now can filter the entire #BlueskyFirehose:
- by keyword: https://firesky.tv/
- by activity type: https://skypulse.dvy.io/
To get a sense of just how centralized the Bluesky topology will be, check out the federation strategy they released today:
https://blueskyweb.xyz/blog/5-5-2023-federation-architecture
In this proposed architecture, all PDSes route through a single massive BGS (big graph service), then downstream via multiple other processing nodes before returning (via a PDS) to users' clients.
H/T @ralf for the link.
@ralf Still trying to puzzle out what problems this odd architecture is designed to solve (or avoid).
One potential clue is Jack Dorsey's Dec 2022 essay entitled "a native internet protocol for social media", which seems far more concerned about resistance to government censorship than delivering a better social experience. https://pastebin.com/HnBUM33b
At the time, it was easy to just read Jack's essay as an explanation for why he'd chosen to make $1M #StartSmall grants to four privacy-focused projects (Signal, Calyx, Tor, + GrapheneOS) in response to the #TwitterFiles disclosure:
Yet when I now compare his essay to bsky's proposed one-way dataflow (PDS --> BGS --> labeller --> AppView/FeedGen --> PDS), then a different question arises ...
Does this bsky architecture just replicate Jack's threat model from when he was running a #BigSocial site?
auth = delegate to PDS
censorship = have govt chase PDSes
bad content = blame labellers
bad algo(s) = blame FeedGen marketplace
Instead of trying to proactively design a better social experience, could the intention be to shed liability for all those thorny problems by ... outsourcing them?
If so, it's trivially easy to imagine scenarios where trusting a single company to provide all these services could lead to familiarly cynical outcomes. Ditto for market-driven scenarios where most of the variety + decentralization happens via PDS-only providers. https://hachyderm.io/@pevohr/110236815460525419
What's harder to envision is a healthier world of federated #SmolSocial services who bundle multiple providers via this architecture, while still resisting BGS centralization + capture. Hmm...
In a similar vein (contrasting bsky vs. nostr):
"What if you rebuilt Twitter [...] as an Open Source project where you made services that replaced all the different layers in the Twitter stack and made it so that at each layer you had can have more than one of them? It doesn't necessarily mean that it's all distributed. It just means that instead of having a singleton there could be at least two providers." -- @rabble
Where + why they chose to draw architectural boundaries:
https://news.ycombinator.com/item?id=35881170
"The general goal is to create a global network that aggregates activity (such as likes) across the entire network, and so we use large scale aggregation services to provide that aggregated firehose. Unless somebody solves federated queries with the sufficient performance then any network that's trying to give a global view is going to need similar large indexes." -- bsky dev Paul Frazee
His threat model:
"The organization is a future adversary. You build the technology knowing you won’t be staying at the company forever, and you signpost the things that protect users/your-future-self. This includes open sourcing everything, moving specs to standards bodies when they stabilize, and building the network around low switching costs.
I can’t predict the future. We may screw it up. I’m trying to protect the community from us if we do."