I would like to give an update on "federation" on Bluesky

@mat @eniko There is already such a Wordpress plugin that publishes to ActivityPub. I believe publishing a Wordpress or other blog as a PDS would be even easier than ActivityPub. All the ATP single-link APIs are very simple and almost even well documented. So the fact this sort of thing (PDS frontend to legacy data source like Wordpress) does not exist is I think a testament to the fact most people in a position to create such things take a look at, and cannot see the benefit of, ATProto interop

@mcc @eniko There are WP AT crosspost-style plugins. If you're crossposting to Bluesky from WP then you probably care about your data sovereignty. I think the demand is there if a developer took on the task. Perhaps genuine WP AP integration only exists because Matthias is so committed.

The difference between Wordpress and Friendica is that WP doesn't really require two-way communication. And that's what I don't get. I know how my posts get sent to the relay, but where are replies to those posts coming from in this setup?

@mcc @eniko There are WP AT crosspost-style plugins. If you're crossposting to Bluesky from WP then you probably care about your data sovereignty. I think the demand is there if a developer took on the task. Perhaps genuine WP AP integration only exists because Matthias is so committed.

The difference between Wordpress and Friendica is that WP doesn't really require two-way communication. And that's what I don't get. I know how my posts get sent to the relay, but where are replies to those posts coming from in this setup?

@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 @mcc @eniko I think you'd be hard pressed to implement AT Proto in PHP tbh..

@mat @mcc @eniko I think you'd be hard pressed to implement AT Proto in PHP tbh..

@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.

@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

@mcc I do, yeah. So it's just one part of the stack. The complicated parts come later, eh?

@mcc @mat @eniko I mean, kinda correct in that WebSockets are tunneled over HTTP, but it's still the WebSocket Protocol that is being used..

@fleeky 1. Correct
2. I don't know

@thisismissem @mat @eniko Okay, yes, that's more accurate.

@mat @eniko Isn't it convenient that Bluesky has architected an "open" system where the solution to every problem turns out to be "use Bluesky", and any other solution requires fighting incredible gravity?

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 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

@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.