I would like to give an update on "federation" on Bluesky.
-
@mcc Link, the banned user in question, is accessible via the raw Bluesky network feed (the "fire hose"). But he cannot be viewed by any server that utilizes Bluesky labelers. Does your PDS?
It seems as though Blacksky does, which is why he can't be seen there. But he can still post. I'm in touch with him and he's posted to me, which you can see here in the fire hose: https://pdsls.dev/at://did:plc:63hvnyjvqi2nzzcsjgnry5we/app.bsky.feed.post
@mattsheffield The pds doesn't view posts. The appview views posts. You need like five separate components in order to look at a post on Bluesky and every single one of them introduces the potential for censorship. I can't read the site through pdsls that's bonkers
-
@mattsheffield The pds doesn't view posts. The appview views posts. You need like five separate components in order to look at a post on Bluesky and every single one of them introduces the potential for censorship. I can't read the site through pdsls that's bonkers
@mcc The layers are indeed censorship choke points.
What I'm saying is that in this case, it appears to be the labeler of Bluesky that's the issue. Any app view that uses it will suppress Link's posts, even if he's not banned locally.
The app view of Blacksky would hide his posts locally but he wouldn't be banned. This is why he can post but can't see them. The Blacksky app view (the site) is independent except for the labeling.
-
@tess I am inclined to give Rudy a lot of leeway because he is clearly moving very fast. I'd rather him engineer than answer my questions and I'd rather not interrupt him while he's engineering a thing I want to use.
But I just want to know what the software I'm using… like… is.
-
@mcc The layers are indeed censorship choke points.
What I'm saying is that in this case, it appears to be the labeler of Bluesky that's the issue. Any app view that uses it will suppress Link's posts, even if he's not banned locally.
The app view of Blacksky would hide his posts locally but he wouldn't be banned. This is why he can post but can't see them. The Blacksky app view (the site) is independent except for the labeling.
@mattsheffield *sighs*
I feel like I'm having a lot of repetitive conversations. The thing you are claiming was my conclusion as of last night, but then I was shown an additional piece of evidence, which makes me conclude something different. This was documented in one of the threads I link above, but I link a lot of things above, so I assume you didn't see it. I can explain it, but it would make more sense to just wait for Rudy (who I've asked for an explanation) to explain.
-
@mattsheffield *sighs*
I feel like I'm having a lot of repetitive conversations. The thing you are claiming was my conclusion as of last night, but then I was shown an additional piece of evidence, which makes me conclude something different. This was documented in one of the threads I link above, but I link a lot of things above, so I assume you didn't see it. I can explain it, but it would make more sense to just wait for Rudy (who I've asked for an explanation) to explain.
@mcc I think I did see it, the one referencing the network traffic from bsky.app? I think that's because the labeling instructions are pulled from there and assembled by the client. So it appears to be an app view issue but is actually a labeling one.
But you're right that only Rudy can clarify this
-
@mcc I think I did see it, the one referencing the network traffic from bsky.app? I think that's because the labeling instructions are pulled from there and assembled by the client. So it appears to be an app view issue but is actually a labeling one.
But you're right that only Rudy can clarify this
@mattsheffield In the screenshot, you see two headers: atproto-accept-labelers, which shows two labelers i assume to be bluesky and blacksky, and atproto-proxy, which indicates which appview is to be used (source: bryan newbold from bluesky), and shows only api.bluesky. So I believe both issues are live. But I am more worried about the appview/atproto-proxy issue, because out of the two, I assume it to be the more difficult issue to fix.
-
@mattsheffield In the screenshot, you see two headers: atproto-accept-labelers, which shows two labelers i assume to be bluesky and blacksky, and atproto-proxy, which indicates which appview is to be used (source: bryan newbold from bluesky), and shows only api.bluesky. So I believe both issues are live. But I am more worried about the appview/atproto-proxy issue, because out of the two, I assume it to be the more difficult issue to fix.
@mcc It's possible that Rudy has an independent app view because that can be part of a PDS, but he is not deploying it because his users wouldn't be able to use a mobile app to interface with.
They tout the ability to log in via the Bluesky app into Blacksky PDS, and possibly this is why that traffic is happening.
I have seen Link's account on another PDS, which does suggest that the app view and labeler are both live issues, as you're surmising. https://social.shatteredsky.net/profile/did:plc:63hvnyjvqi2nzzcsjgnry5we
-
@mcc It's possible that Rudy has an independent app view because that can be part of a PDS, but he is not deploying it because his users wouldn't be able to use a mobile app to interface with.
They tout the ability to log in via the Bluesky app into Blacksky PDS, and possibly this is why that traffic is happening.
I have seen Link's account on another PDS, which does suggest that the app view and labeler are both live issues, as you're surmising. https://social.shatteredsky.net/profile/did:plc:63hvnyjvqi2nzzcsjgnry5we
@mattsheffield I do not think, in the context of the post you have made here, shatteredsky is "a PDS". I think we are using terminology differently and this is making it difficult for me to follow the conversation.
-
@mattsheffield I do not think, in the context of the post you have made here, shatteredsky is "a PDS". I think we are using terminology differently and this is making it difficult for me to follow the conversation.
@mcc It is both a PDS and an app view. I'll be publishing a piece about this later today after getting more info. Nothing from Rudy though
-
@mcc I stay as far away from Dorsey as possible, and they banned LINK?!?!!!
@Bigshellevent @mcc Dorsey quit Bluesky in May 2024.
-
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
@mcc@mastodon.social amazing thread. so clear even explaining what you’re not clear about. but it does make me feel like it shouldn’t be this complicated. i haven’t looked at atproto but everything i read makes me not want to.
-
@mcc@mastodon.social amazing thread. so clear even explaining what you’re not clear about. but it does make me feel like it shouldn’t be this complicated. i haven’t looked at atproto but everything i read makes me not want to.
@ellyxir I honestly don't think their architecture is very good
-
@mcc It is both a PDS and an app view. I'll be publishing a piece about this later today after getting more info. Nothing from Rudy though
@mcc I filed my report.
Got quotes from Link and Bluesky about the federation situation and why Blacksky was affected. It was their use of Bluesky's appview (aka appserver) which forced them to be affected by Bluesky's moderation decisions.
It appears there are not any independent, full stack implementations of ATProto, but a company is trying to build a system to make appview deployment much easier: https://plus.flux.community/p/banning-controversy-reveals-blueskys
-
@mcc it's certainly possible! I didn't think they were running a separate appview yet but I could easily be wrong.
(blacksky.community is currently a fork of the Blluesky app-aka-client, it hasn't diverged much yet. not sure if and when they're planning on writing their own implementation of that)
@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.)
-
@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)
