I would like to give an update on "federation" on Bluesky.
-
@lrhodes @mat @mcc @alter_kaker @esoteric_programmer """fun""" fact btw: canonicity of at:// uri is different depending on whether you use the did or dns as the authority. so at://atproto.com has different properties than at://did:plc:ewvi7nxzyoun6zhxrhs64oiz -- the former will break if the dns handle ever changes, and the latter is supposed to be used whenever canonical references are needed. but guess which one gets exposed to user-facing stuff? that's right, did is backend, dns is frontend.
@trwnh @lrhodes @mat @mcc @alter_kaker I thought
@user.domain.tldis just a way to point to@did:plc:blahblahblah, the same way we do with webfinger over here. Wouldn't this difference in the protocol make an impersonation attack more possible? -
@trwnh @lrhodes @mat @mcc @alter_kaker I thought
@user.domain.tldis just a way to point to@did:plc:blahblahblah, the same way we do with webfinger over here. Wouldn't this difference in the protocol make an impersonation attack more possible?@esoteric_programmer @lrhodes @mat @mcc @alter_kaker you are *supposed* to "convert" the user.domain.tld to did:plc:blah, but you can still construct references against user.domain.tld. but you're not supposed to. but every user-facing component only shows you the user.domain.tld instead of the did:plc:blah, so if you're just copying from your address bar, you are going to get the "wrong" identifier most likely.
it has the exact same properties as letting a dns name lapse and get reassigned.
-
@eniko the advantage is the data is yours and you can recover it later if Bluesky goes berserk. This is a mild advantage but in keeping with the mild advantages operating a PDS is also a mild imposition. It's practically a git repo with a weird frontend. I'm not saying self host but if people are starting to host alternate bluesky bits, this is the most likely thing for someone to alternate host (because it is the least demanding thing) so it's the most likely option to appear.
@mcc @eniko The part I was hoping for was an AT plugin for Friendica (or Wordpress) that turns my instance into a PDS. It sounds like you'd still need an account on either bluesky or blacksky though, which is sad. But that way I keep my single identity, and conversations wouldn't be completely split between the two networks. I'm just missing an architecture diagram that shows at which points it plugs into the bluesky tower. -
@tylercook like, absurdly easy. Do you know Docker or any Docker-like system?
@mcc I do, yeah. So it's just one part of the stack. The complicated parts come later, eh?
-
@mcc @eniko The part I was hoping for was an AT plugin for Friendica (or Wordpress) that turns my instance into a PDS. It sounds like you'd still need an account on either bluesky or blacksky though, which is sad. But that way I keep my single identity, and conversations wouldn't be completely split between the two networks. I'm just missing an architecture diagram that shows at which points it plugs into the bluesky tower.
@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
-
@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
@mat @eniko Another thing to note. Posts on ATProto are 300 characters. The entire system is set up to mark "schema invalid" and wholly censor any post which is more than 300 characters. So what you'd have to do is put a 270 character summary of your post, plus a link to your real wordpress, into the PDS. (It's not a schema violation to contain *extra* data, so you could include a "full-text" field in the post blob, but no system in existence could read it— not even yours, you'd be publish-only)
-
@mat @eniko Another thing to note. Posts on ATProto are 300 characters. The entire system is set up to mark "schema invalid" and wholly censor any post which is more than 300 characters. So what you'd have to do is put a 270 character summary of your post, plus a link to your real wordpress, into the PDS. (It's not a schema violation to contain *extra* data, so you could include a "full-text" field in the post blob, but no system in existence could read it— not even yours, you'd be publish-only)
@mat @eniko So at that point, barring building an entire alternate Bluesky-like system for reading longposts— a system which would be redundant when ActivityPub exists— you're not mirroring your WordPress on Bluesky, rather you're using Bluesky as a funny kind of RSS feed, posting a short announcement of each post there… at which point, isn't it easier to just link your WordPress to a *regular* bluesky account, and use the API to auto-post summary+announcements for new posts?
Am I making sense?
-
@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?
-
@mat @eniko So at that point, barring building an entire alternate Bluesky-like system for reading longposts— a system which would be redundant when ActivityPub exists— you're not mirroring your WordPress on Bluesky, rather you're using Bluesky as a funny kind of RSS feed, posting a short announcement of each post there… at which point, isn't it easier to just link your WordPress to a *regular* bluesky account, and use the API to auto-post summary+announcements for new posts?
Am I making sense?
-
@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 @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.
