I would like to give an update on "federation" on Bluesky.
-
@mat @eniko "but where are replies to those posts coming from in this setup?"
Short version: "You can't get them"
Long version: Currently the only ways to get replies to a post published in your Bluesky PDS are
- Run a "relay". This means (this is not a joke) receiving from Bluesky PBC a copy of literally every post made in the network, and filtering for ones that @ you.
- Log in to bsky.app (or a clone like blacksky) with your PDS username and password, and look in the notifications tab.
@mat @eniko Now, that last thing is possible, and even easy. But at that point it's really, super unclear *why* you would architect your Wordpress server to *be* a PDS, rather than running the regular PDS software on the same box, and having the Wordpress server post to it from time to time using the external API. It's extra work, but there's no obvious advantage and there's barely even a difference.
-
@mcc @thisismissem @eniko ...and that reminds me of another thing!
In the spec it says "In addition to regular HTTP API endpoints, atproto supports continuous event streams." And indeed, implementing the event stream seems hard. But HTTP APIs don't sound hard. So... do PDS's have to implement both? It sounds like they don't.
-
-
@mat @eniko Now, that last thing is possible, and even easy. But at that point it's really, super unclear *why* you would architect your Wordpress server to *be* a PDS, rather than running the regular PDS software on the same box, and having the Wordpress server post to it from time to time using the external API. It's extra work, but there's no obvious advantage and there's barely even a difference.
-
@mcc @thisismissem @eniko ...and that reminds me of another thing!
In the spec it says "In addition to regular HTTP API endpoints, atproto supports continuous event streams." And indeed, implementing the event stream seems hard. But HTTP APIs don't sound hard. So... do PDS's have to implement both? It sounds like they don't.
@mat @mcc @eniko yeah, because you need sync, afaik. https://atproto.com/specs/sync
-
@mcc @thisismissem @eniko ...and that reminds me of another thing!
In the spec it says "In addition to regular HTTP API endpoints, atproto supports continuous event streams." And indeed, implementing the event stream seems hard. But HTTP APIs don't sound hard. So... do PDS's have to implement both? It sounds like they don't.
@mat @thisismissem @eniko The continuous event streams are HTTP. Mine are being proxied through Apache
-
@mat @thisismissem @eniko The continuous event streams are HTTP. Mine are being proxied through Apache
-
@mcc I do, yeah. So it's just one part of the stack. The complicated parts come later, eh?
@tylercook Yes, correct. If you already have a setup for hosting Docker containers standing up the PDS is *trivial*. Like, you could do it in under an hour. I don't pay per byte of bandwidth (VPS) but the load from running my PDS has been so low I don't notice it. And if it turns out to be a problem you can migrate out to another PDS.
I'm going to DM you a link to a Discord I found helpful when debugging issues with my PDS.
-
@thisismissem @mat @eniko Okay, yes, that's more accurate.
-
@fleeky 1. Correct
2. I don't know@mcc am having a discussion of this on bsky that is helping to disambiguate :
https://bsky.app/profile/futur.blue/post/3lyuzwzb2k226
also https://github.com/zeppelin-social/bluesky-appview -
@thisismissem @mat @eniko Okay, yes, that's more accurate.
@mcc @mat @eniko so yeah, I was more saying PHP and WebSockets isn't likely to be the most pleasant time for someone. (much like Ruby and WebSockets)
But yeah, if you're suggesting a sidecar PDS to a wordpress blog that just publishes bluesky posts with a link to the wordpress post, then that'd be relatively simple. It's once you want to go beyond that that things start getting hard.
-
@mcc @eniko I kinda feel like giving them the benefit of the doubt. All of these decisions can be explained by their goal of being Twitter 2.0, instant distribution to millions of people, everyone's eyeballs glued to the very latest posts as they continually fly past, desperate to respond in a way that generates traction before the world's attention fades. That's a hard problem to solve! The fact that I can't imagine why I would want it solved for me is not the point.
-
Why does the "relay" matter? Well, because although Bluesky's claim is that moderation is "composable" in their system— that you can choose which moderators to follow— moderation decisions made by Bluesky are hard binding on systems they control. Someone blocked by Bluesky is blocked from the Bluesky appview, their content will get removed from the Bluesky PDS if they were using that. The Bluesky relay censors content that violates the data "schema"; I suspect (?) it enforces moderation also.
@mcc Content doesn’t get removed from the PDS it would be hidden by labels - accounts do have takedown labels applied.
Bluesky operated relay doesn’t censor Lexicons that don’t validate and it doesn’t enforce moderation.
For those following along at home the relay costs about $30/month to run for all ~38M accounts worth of content.
-
@mcc Content doesn’t get removed from the PDS it would be hidden by labels - accounts do have takedown labels applied.
Bluesky operated relay doesn’t censor Lexicons that don’t validate and it doesn’t enforce moderation.
For those following along at home the relay costs about $30/month to run for all ~38M accounts worth of content.
@boris "Content doesn’t get removed from the PDS it would be hidden by labels - accounts do have takedown labels applied." I could be wrong but this seems to be contradicted by actual events over the last two weeks.
"Bluesky operated relay doesn’t censor Lexicons that don’t validate" Contradicted by my own testing. Either the relay censors them or the appview does and it comes to the same thing, because when I make 301-character posts even third party tools can't see them.
-
@mcc am having a discussion of this on bsky that is helping to disambiguate :
https://bsky.app/profile/futur.blue/post/3lyuzwzb2k226
also https://github.com/zeppelin-social/bluesky-appview@fleeky As an update, I searched on blacksky.community for "from:me blackbird" and found a post from 2024. So they have some source of older posts.
-
@boris "Content doesn’t get removed from the PDS it would be hidden by labels - accounts do have takedown labels applied." I could be wrong but this seems to be contradicted by actual events over the last two weeks.
"Bluesky operated relay doesn’t censor Lexicons that don’t validate" Contradicted by my own testing. Either the relay censors them or the appview does and it comes to the same thing, because when I make 301-character posts even third party tools can't see them.
@mcc accounts get taken down! Posts do not / individual posts doesn’t get removed out of the repo (would also break verification of a repo and is detectable)
yes apps all choose their validation (and for that matter strong types). Regardless it’s not the relay that’s doing it if you’d like to be correct about where locus of control is.
-
@mcc accounts get taken down! Posts do not / individual posts doesn’t get removed out of the repo (would also break verification of a repo and is detectable)
yes apps all choose their validation (and for that matter strong types). Regardless it’s not the relay that’s doing it if you’d like to be correct about where locus of control is.
@boris "(would also break verification of a repo and is detectable)"
What happens if I delete a post from a repo? If it can't be removed can someone then query the post from my PDS direct and get a copy of the deleted content?
-
@boris "(would also break verification of a repo and is detectable)"
What happens if I delete a post from a repo? If it can't be removed can someone then query the post from my PDS direct and get a copy of the deleted content?
@mcc Bsky doesn’t have auth on your account and can’t delete individual posts.
The user can delete posts as they like and then it’s truly deleted and can’t be queried.
-
@mcc Blocks are "enforced" at the client level. I know, I know, that probably merits another "oh dear" but that's how Bluesky is doing it. So blacksky.community as a client doesn't do age verification for DMs in the UK, or block access to Mississippi.
Takedowns by contrast are at the AppView and someties PDS level.
@jdp23 Rudy says they're appview and also client. https://bsky.app/profile/rude1.blacksky.team/post/3lyvbqh3m3s2e
-
As an update since posting the above thread I have received replies from two people, one saying I am underestimating the level of stack coverage Blacksky has, another saying I am overestimating it.
The stack is just so tall! There are *so many* layers in this protocol's model. And it seems like every single one of them is an opportunity to introduce censorship
Update: Rudy who operates blacksky.community responded to this thread on bluesky. Above I said I wasn't clear on how independent Blacksky was of the Bluesky infra. His answer is "completely". They run their own relay (which scrapes PDSes itself), the relay feeds into their own appview, the appview feeds into their own client. https://bsky.app/profile/rude1.blacksky.team/post/3lyv5rwpc722c
And since they bridge end-to-end, in my Hypothetical Example above, they *could* choose to make different moderation decisions from Bluesky PBC.
