Piero Bosio Social Web Site Personale

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

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

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

@erincandescent I have an entirely workable proposal for how to achieve that in a distributed system, which the mastodon dot social post length is too small to contain

@erincandescent i think in order to solve this problem without centralization you do need a ledger ("blockchain"). That's simply the way to get a canonically agreed on ordering of events. I think there are some reasons to go with a data structure *other* than literal blockchain for your ledger. But if you create a canonically agreed on ordering of events (which as far as I'm concerned you need if you want to support key rotation/did changes) then more or less by definition you've made a ledger

@trwnh @erincandescent @ikuturso @jrose this raises an important question. Why the fuck are we not just using a pki to start with

@trwnh yes, that's why in my example I picked the first three letters of "kademlia"

@trwnh @erincandescent @ikuturso @jrose I am proposing inventing a did:kad, or a did:kad2 if did:kad is already being used, and giving it whatever properties would be needed to make it work the way I said.

And yes, I'm proposing creating an exact clone of plc that doesn't depend on plc.directory.

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

@erincandescent @ikuturso @trwnh @jrose I am proposing engineering a situation where did:plc:eepire and did:kad:eepire point to the same resource.

@eniko Yes, I think these are great points.

@trwnh @ikuturso @jrose if someone develops a better did method, surely you could just have two DIDs point to the same repo? Use Good DID with non-bluesky systems and Bad DID with bluesky systems. Maybe they could even have the same "key" (the Z in did:Y:Z)

@eniko I think M Kasprzak actually has a fork of the official Bluesky PDS, right now, that also publishes to ActivityPub. I think Wafrn can do that too. So that would be an example of "bridging" like I mean— you could start syndicating your bluesky posts to Fediverse, and if you ever bug out from Bluesky just disconnect those endpoints and now you've just got a fediverse server. But this scenario assumes you weren't already more established and comfortable on Fediverse than Bluesky to start with

@tylercook like, absurdly easy. Do you know Docker or any Docker-like system?

@eniko In a world where Mastodon/ActivityPub doesn't exist, having the PDS would be a cool opportunity because if you ever do bug out from bluesky, instead of having to find someone replicating that giant teetering ATProto stack you could bridge to, or create, some kind of alternative system. But in this actual world this feels pointless since the alternative systems (like ActivityPub) that exist already are more capable to begin with, so why not just make the posts there to begin with.

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

@ikuturso @lrhodes @esoteric_programmer @alter_kaker yeah, that thing