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 -
@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@mcc yeah have a look at Rudy's thread there, he makes that very clear. And similarly Northsky is saying well, our original plan was do PDS as Phase 1, Relay as Phase 2, and AppView as Phase 3, but now we're acceslerating Relay and AppView up and treating it all as Phase 1. My take is that everybody always took the approach of treating Bluesky PBC as a potential adversary but didn't expect them to be this adversarialy this quickly.
(If this is all an N-dimensional chess play to blow up the company to speed up the decentralization ... well as shitposting goes, that's pretty darned epic. But it's probably just horrbile comms accelerating and magnifying the tensions that were always inherent. Time will tell I guess.)
@by_caballero it's true that's a huge hole in the composable moderation model (and Rudy and others had been looking at it even before this -- https://discourse.atprotocol.community/t/how-should-we-fairly-split-the-costs-of-commons-moderation-across-producer-and-consumer-apps/122 is interesting thinking from the Eurosky perspective although doesn't yet point to any conclusions). But for this particular case they just need an appeal method for community members that allows themm to override the Bluesky mod service's app-level takedowns in their own AppView. On the deeper issue though I feel pretty vindicated because I've always said that composable moderation is interesting and valuable in some important use cases but doesn't actually solve the moderation scalability issue.
-
@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)
-
The biggest movement on this front has come from the community formerly known as Black Twitter, which now has complete, viable alternative dupes of the whole stack:
Rudy wants revolution. (@rude1.blacksky.team)
blacksky.app → pds atproto.africa → relay blacksky.community → app @blackskyweb.xyz → moderation @tektite.cc → migration assembly.blacksky.community → governance blackskyweb.xyz → marketing website rsky.satnav.dev → exported data explorer https://blacksky.community
Blacksky (blacksky.community)
This makes intuitive sense to me! My first question, looking at ATP, is "why do free dev for this protocol, controlled by one corporation, when Fediverse is right there and is more complete?". But the black dev community, from everything I saw, tried to adopt Fediverse *first* and basically got harassed off.
@mcc It's a damned shame that the Fediverse didn't succeed in keeping the Black developer community around.
-
@mcc Bluesky is a venture capital shit show in the making. The rug pull will happen in the next decade.
I did not know about the fighting between black devs and the queer community.??? What is the lore there.
Cuz it sux that they went the way of atproto over activity pub.
"what is the lore here"
Basically a lot of people (some even supposedly being grown-ups) cared about what other people who didn't have their best interests in mind said. -
@feld @aeva @mcc I think mastodon.social's chunk of the fedi network isn't anywhere near as large as the bsky operated service is relative to its network. And there's plenty of (mostly?) healthy skepticism about and pushback against "too-big" servers.
That does need to be tempered with the reality that tiny personal or community servers have issues too (time/money to operate, migration not being truly seamless -- can't take your identity or posts with you, what server is right for me?, etc)
-
@msh @swetland @gbargoud From what I see, some communities were driven away by community issues, others (im thinking indie gamedev Twitter and comics artists) just couldn't navigate the additional friction of Mastodon's model. It wasn't all one thing. And I doubt you can chalk up the community issues to just one server, or at least, if there were one server I don't think it would be mastodon dot social (I have an instance in mind but don't feel like naming names)
In general, the bottleneck of social media is moderation. Big servers get that problem, a lot of small community servers don't. At the same time, that's when the resilience of decentralization really kicks in. By default the dominant idea of the internet and VC for the last 25 years is and was "big is beautiful" and the more followers I have the more important and valuable I am.
The fedi should and actually wants to be something different.
-
@mcc yeah have a look at Rudy's thread there, he makes that very clear. And similarly Northsky is saying well, our original plan was do PDS as Phase 1, Relay as Phase 2, and AppView as Phase 3, but now we're acceslerating Relay and AppView up and treating it all as Phase 1. My take is that everybody always took the approach of treating Bluesky PBC as a potential adversary but didn't expect them to be this adversarialy this quickly.
(If this is all an N-dimensional chess play to blow up the company to speed up the decentralization ... well as shitposting goes, that's pretty darned epic. But it's probably just horrbile comms accelerating and magnifying the tensions that were always inherent. Time will tell I guess.)
@by_caballero it's true that's a huge hole in the composable moderation model (and Rudy and others had been looking at it even before this -- https://discourse.atprotocol.community/t/how-should-we-fairly-split-the-costs-of-commons-moderation-across-producer-and-consumer-apps/122 is interesting thinking from the Eurosky perspective although doesn't yet point to any conclusions). But for this particular case they just need an appeal method for community members that allows themm to override the Bluesky mod service's app-level takedowns in their own AppView. On the deeper issue though I feel pretty vindicated because I've always said that composable moderation is interesting and valuable in some important use cases but doesn't actually solve the moderation scalability issue.
@jdp23 @mcc not adversary (directly), just forced to be less cooperative by being a US entity under meddling FCC and congress! I would also note that how bsky.app shows content to bsky users NOT applying their own blocklist/mod service is uncharted and unspecified territory. they never promised they even would and reserve the right to just not. its a hard problem! I refer to it as "federated moderation" and its totally fair they never even promised to try doing it
-
@jdp23 @mcc not adversary (directly), just forced to be less cooperative by being a US entity under meddling FCC and congress! I would also note that how bsky.app shows content to bsky users NOT applying their own blocklist/mod service is uncharted and unspecified territory. they never promised they even would and reserve the right to just not. its a hard problem! I refer to it as "federated moderation" and its totally fair they never even promised to try doing it
@jdp23 @mcc also note: there is a weird migration corner-case where the "blob store" of high-activity/high-attachment-volume accounts seems to glitch out when people move between PDS implementations. fascinating from the POV of someone who's been studying migration corner-cases in both protocols for years 🤯
https://bsky.app/profile/matthewcort.land/post/3m2nvkpx5tc2d -
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)
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)
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)
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?)
-
@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?)
@mcc @whitequark reminds me of the good(*) old days when the Twitter firehose was open... Surely history would never repeat...
(*) in hindsight probably not actually.
-
@mcc it's such a confusing aspect of the protocol. why does everything need the firehose? how do they expect it to scale??
@whitequark @mcc given the history of the whole thing, I find it exceedingly likely that this is a feature rather than a bug, i.e. the entire premise of it was to capture an emerging market and user-base by riding the decentralisation buzz and tying it into blockchain/web3 (and NFTs to a lesser extent). it's also on brand - solutions that purport to empower users while really just maintaining plausible deniability for control and financial gain are the lifeblood of that class of technologist.
-
Follow up, 2025-12-27: Rudy here confirms the Blacksky appview is still being worked on (eg: blacksky uses bluesky's appview still)
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.
:frogsiren: BLUESKY HAS OFFICIALLY NETSPLIT :frogsiren:
There has always been more than one Fediverse. Different instances make different moderation decisions so some instances can't see posts by some users.
There has only ever been one Bluesky because every ATProto frontend uses the same Appview.
It is January 2026 and that's no longer true; Blacksky's Appview is available for beta use and there is at least 1 user banned on Bluesky but not Blacksky. And vice versa.
Rudy wants revolution. (@rude1.blacksky.team)
Bluesky runs an appview. Blacksky runs an appview. A complete appview is a several terabytes sized database of the >18 billion follows, likes and posts of all bsky users, ever and forever. To run a different appview is to make a fork in bsky’s timeline. One has new posts from Łink. One doesn’t.
Bluesky Social (bsky.app)
