Next step with AT Proto

I’m considering some improvements to our Bluesky and AT Protocol implementation in Micro.blog. Currently we can cross-post blog posts to Bluesky, either manually or automatically whenever you post to your blog. You can also follow Bluesky users directly in Micro.blog. You can even browse Bluesky starter packs.

There are several directions we could go from here. At one point, I thought PDS hosting would be the next step, but it still feels too early for that, and it would be a daunting infrastructure change. I’d like to instead focus on lexicons.

When we post to Bluesky, short posts under 300 characters are preserved mostly as-is, with inline links and photos. Longer posts are truncated. Posts with titles are linked back to your blog, including the post summary if it’s set.

Meanwhile there are people in the AT Protocol community exploring long-form content, such as WhiteWind and Leaflet. My rough plan is:

• Add an option to Micro.blog cross-posting for Bluesky that also copies long-form posts to Leaflet’s structured format. I hope that this might help spur interest in Leaflet. Leaflet uses a block-based document format, and Micro.blog would essentially convert HTML to this format as best it can, with each paragraph or image becoming a block.
• Add a new embed type for long-form posts with a new lexicon that removes the 300-character limit, adding an optional title field and other things. This way, Bluesky clients would continue to see the truncated post in the timeline, but clients that are aware of this new embed could extract it and show a “read more” link or just include the full text.

Posts in Bluesky can only have a single embed, which is a union that could be one of several types. The most common embed is an array of images. Another embed is the Open Graph preview. A new blog.micro.embed.post lexicon would be an additional embed.

Let me try to visualize this structure with a diagram of two posts. The first is a simple short microblog post. The second is a microblog post with the full-length blog post embedded in it.

Note there are a couple of potential issues here, and probably others I haven’t run into yet:

• Because there can only be one embed, we’d lose the very useful array of images attached to a post. Instead, we’ll recreate this as an images field inside the embed, so Bluesky clients can fall back on that.
• Because real blog posts often have inline images, we’ll add a new rich text facet type blog.micro.richtext.image that represents an image. In the same way you could have a range of text that is a link or @-mention, you could have a range of text that is an “image” and should be replaced in a post renderer with the image, or linked to open the image.

Of course it’s a slippery slope to just reinventing HTML. I’ve included an optional html field that has a copy of the blog post as the author intended. If available, clients could choose to show that in an embedded web view. But by attempting to stick with Bluesky’s rich text and facets wherever possible, it feels like it is a little more at home with the network.

I’ve published drafts of this on GitHub: blog.micro.embed.post and blog.micro.richtext.image. Feedback welcome. These are not finalized and might be wrong or later change in breaking ways until I actually write the code.