I would like to give an update on "federation" on Bluesky.
-
@mcc mmmmkay it looks like Rudy is now in the process of "standing up an app.bsky.* API server" (aka appview) which "Is different from our community.blacksky.* API which is going on hold". So, my best guess is that his answer to you reflected the architecture (where the ommunity.blacksky,* API server is conceptually part of blacksky,.community) rather than the currently-available public implementation at the time.
(And no idea whether he's standing up an early implementation of their Rust appview or doing the off-the-shelf Bluesky appview or something else.)
@jdp23 What's interesting to me here is, the bluesky line is "ha ha it's super good everyone is angry at us because it accelerates federation", but you're making it sound like Rudy is having to upend his software engineering schedule to do stuff he otherwise wouldn't have had to do at all early, because of this incident forcing him to protect his users
-
@mcc what exactly is the benefit of migrating to a non bluesky PDS? I understand being on an entirely different vertical stack like Blacksky or Northsky but what does being on a PDS give you? Aren't you still (almost) entirely at bluesky's mercy?
-
-
@jdp23 What's interesting to me here is, the bluesky line is "ha ha it's super good everyone is angry at us because it accelerates federation", but you're making it sound like Rudy is having to upend his software engineering schedule to do stuff he otherwise wouldn't have had to do at all early, because of this incident forcing him to protect his users
@mcc @jdp23 here guys this might help clarify why Rudy has to rearrange his epics in jira:
https://whtwnd.com/bnewbold.net/3m2j6ccx2bs2t
moderation can only be additive until/unless you pony up the CSAM/hashmatch API key money plus roll and run yr own mod sys at scale. thats the real Achilles heel of composable moderation-- replacing the bottom layer is incredibly expensive -
@anna @adrienne @eniko @mcc all the records in your PDS contain references to your identity (DID document), it's theoretically possible to modify the data to change that but requires rewriting your entire PDS for that account, so not particularly practical.
It's the DID that is moderated against in the higher layers, not your handle.
So it doesn't matter if you're @fred.example or @jason.example, if the DID used for one becomes the DID used for another handle.
It's kinda like how on ActivityPub, software has often encoded your username into the identifier for all your posts, meaning you can't change it without breaking everything.
(Though Mastodon is starting to fix this long-standing issue, there's fix only applies on new accounts, there's no protocol level way to fix it yet — it's kinda a weakness in JSON-LD)
-
So. The thread above. An update.
We finally got a live test of the "Gertrude scenario", when a popular Blacksky user got permbanned by Bluesky. I, using my own PDS and blacksky's website, can't see him or his posts ( https://blacksky.community/profile/did:plc:2aebn3xk5t63net43eeepire/post/3m2iokicegs2b ). What gives?
A lot of people claim this is because Blacksky really is using Bluesky's appview, and gave me a way to verify this looking at headers. This seems to contradict Rudy's previous claims. I've asked Rudy for clarification: https://bsky.app/profile/did:plc:2aebn3xk5t63net43eeepire/post/3m2jve23cf22m
Follow up, 2025-12-27: Rudy here confirms the Blacksky appview is still being worked on (eg: blacksky uses bluesky's appview still)
Rudy wants revolution. (@rude1.blacksky.team)
Funding for Cash comes from CCI and the Cypherpunk Fellowship ($70K total). I am still working on the app-view. I hit storage limits on the previous server during backfill and needed to buy a $14K OVH Cloud instance.
Bluesky Social (bsky.app)
The sticking point, as he describes it, is "backfill". This alludes to the issue that makes me compare ATProto to blockchain: to get the features users expect, every node on the network must mirror the network's entire history. This is impractical, which is why bluesky is as of this moment a federated network with effectively only one node.
-
Follow up, 2025-12-27: Rudy here confirms the Blacksky appview is still being worked on (eg: blacksky uses bluesky's appview still)
Rudy wants revolution. (@rude1.blacksky.team)
Funding for Cash comes from CCI and the Cypherpunk Fellowship ($70K total). I am still working on the app-view. I hit storage limits on the previous server during backfill and needed to buy a $14K OVH Cloud instance.
Bluesky Social (bsky.app)
The sticking point, as he describes it, is "backfill". This alludes to the issue that makes me compare ATProto to blockchain: to get the features users expect, every node on the network must mirror the network's entire history. This is impractical, which is why bluesky is as of this moment a federated network with effectively only one node.
@mcc its really weird for it to be controversial to compare ATProto to blockchain when it was an explicit selling point of the protocol before blockchains became embarrassing to develop for!!
-
Follow up, 2025-12-27: Rudy here confirms the Blacksky appview is still being worked on (eg: blacksky uses bluesky's appview still)
Rudy wants revolution. (@rude1.blacksky.team)
Funding for Cash comes from CCI and the Cypherpunk Fellowship ($70K total). I am still working on the app-view. I hit storage limits on the previous server during backfill and needed to buy a $14K OVH Cloud instance.
Bluesky Social (bsky.app)
The sticking point, as he describes it, is "backfill". This alludes to the issue that makes me compare ATProto to blockchain: to get the features users expect, every node on the network must mirror the network's entire history. This is impractical, which is why bluesky is as of this moment a federated network with effectively only one node.
@mcc it's such a confusing aspect of the protocol. why does everything need the firehose? how do they expect it to scale/?
-
@mcc it's such a confusing aspect of the protocol. why does everything need the firehose? how do they expect it to scale/?
@whitequark If hypothetically, just hypothetically, we imagine that a core design requirement of the protocol was "regardless of what happens in future, it must continue to be necessary that the company Bluesky LLC exists"… the decision becomes a lot less confusing.
-
@whitequark If hypothetically, just hypothetically, we imagine that a core design requirement of the protocol was "regardless of what happens in future, it must continue to be necessary that the company Bluesky LLC exists"… the decision becomes a lot less confusing.
@whitequark (More charitably: If one considered fast, full-text search to be a highest priority feature, and it was merely *unimportant* to the designer whether a second full-service node could ever function… then one might make the decisions bluesky made here.
As for scaling, I assume when the day comes they need it to actually scale they'll either discontinue or break the externally-published linear event stream?)
