I was very happy to see this post on Bluesky this morning from a friend, Matthias Pfefferle, who works at Automattic on the connection between WordPress and ActivityPub.

In his post he asks if there is a BDG for creating a PDS for Bluesky.

A BDG is a Busy Developer's Guide, something we did first for SOAP in 2001 when we were trying to figure out how to map XML-RPC onto it. Since then there have been lots of BDGs for all kinds of things. It's a useful concept because developers are often overly busy, so we need to get right to the problem before understanding all the theory behind it. We need an example that works, and we'll just do what it does. That also guarantees interop, which is the point of course.

Now we have a similar problem. Bluesky stores a user's writing in a PDS. If we can generate a PDS for our blogs, theoretically Bluesky should be able to see them and use them as if they were created inside Bluesky. If it were easy to understand we could get busy converting everything so it works there. We can do that because we're using popular simple formats like JSON (see below) to organize our work.

For example this is how I use JSON for my blog, the one you're reading right now.

• Here's a folder in a repository on GitHub. Broken down into years, months, days, and posts.
• Each post is a JSON file, like this. It has three bits of data, the text of the post, when it was created (which also serves as a unique ID, no two posts have the same creation date) and type. This item has a type of outline, because it can have structure, though this post does not.
• Here's another post that does have structure. In Bluesky it would be represented as a thread.

Here's the question. What's the absolutely simplest way to have that structure of posts represented in a Bluesky PDS?

PS: I had a conversation with ChatGPT to scope this out.