Combine this extension with gadenbuie/bluesky-comments

[gadenbuie]

Let's make one, really great Bluesky comments extension with all the features!

I've talked to the Quarto team and they've agreed that we could create a single bluesky-comments extension in the quarto-ext org, as long as we agree to continue maintenance.

If you're open to that idea, I'd like to propose that we start with your extension. Your documentation is excellent and the Lua interface is quite nice and definitely what I had in mind as well.

If that sounds good to you, here's a sketch of how we could move forward. Feel free to propose other plans (or to decline entirely, I'll understand):

1. I could spend a bit of time consolidating our JavaScript implementations so we have a unified extension
2. Once merged we could create a new quarto-ext/bluesky-comments with the git history from this project (but not as a fork to avoid confusion).
3. Then we add notices at the top of our repos and archive them.

If you want, I could outline the first consolidation point, or we could just collaborate in the PR as I go. Let me know how this all sounds to you.

[coatless]

@gadenbuie Okidokies. Sound good. How about we move this repo over to quarto-ext now with a development disclaimer?

[gadenbuie]

Awesome! I've started working on unifying the extensions and I'd be happy to just start with that work in quarto-ext. Before I do that, I just want to run a couple largish changes by you.

I mentioned this first one in our Bluesky conversation, but I'd like the shortcode to support using the post URL as well as the atproto URI. The path I've started down is to take both and then emit a console message if the resolved thread.post.uri doesn't match the user-provided post URL. In the future, we could also make this message more visible in local previews.

Relatedly, I'd like the shortcode to take the post URI directly as an unnamed argument, e.g.

{{< bluesky-comments https://bsky.app/profile/coatless.bsky.social/post/3lbtwdydxrk26 >}}

{{< bluesky-comments at://did:plc:fgeozid7uyx2lfz3yo7zvm3b/app.bsky.feed.post/3lbtwdydxrk26 >}}

Both of these changes are designed to minimize as much as possible any user-level friction around adding the comments to an existing post.

The downside of using the post URL, of course, is that it's not as stable as the resolved atproto URI. To resolve this, I've also implemented a change where you can put your profile in _quarto.yml or the post metadata

bluesky-comments:
  # profile: did:plc:fgeozid7uyx2lfz3yo7zvm3b
  profile: coatless.bsky.social

and then use the post ID directly in the shortcode

{{< bluesky-comments 3lbtwdydxrk26 >}}

This would make it easier to a) globally change the profile name or b) lookup your DID once and never have to do it again.

In the future, I'm envisioning another feature to lean on the YAML frontmatter so that you could add

bluesky-comments:
  # post: at://did:plc:fgeozid7uyx2lfz3yo7zvm3b/app.bsky.feed.post/3lbtwdydxrk26
  post: https://bsky.app/profile/coatless.bsky.social/post/3lbtwdydxrk26

at the top of an existing post to have the comments section added automatically without having to use the shortcode. The goal would be to further reduce the amount of editing required when you come back to add the post URL to an existing post.

Let me know what you think of these proposals. If they sound okay to you (or at minimum like a workable start), I'll work on bringing this all to the quarto-ext org.

[coatless]

Thanks for the detailed proposal! Let me share some context about the design choices.

The explicit uri requirement in the shortcode was initially a hedge - I had considered adding a pre-render script to convert post URLs to DIDs automatically, turning:

{{< bluesky-comments https://bsky.app/profile/coatless.bsky.social/post/3lbtwdydxrk26 >}}

into:

{{< bluesky-comments https://bsky.app/profile/coatless.bsky.social/post/3lbtwdydxrk26 uri="at://did:plc:fgeozid7uyx2lfz3yo7zvm3b/app.bsky.feed.post/3lbtwdydxrk26" >}}

However, since there wasn't clear precedent for using project-level pre-render/post-render with extensions, I kept things simpler. Given the interest in extensions for bluesky-comments, I wanted to maintain that simplicity for the first release.

I'm very supportive of your YAML configuration approach! I've experimented with similar metadata placement in filters via stamp (see examples at _extensions/stamp/stamp-document.lua#L85-L103 and template.qmd).

Regarding the 3x extensions issue ticket:

I'm aiming to potentially add a few useful widgets for BlueSky into either bluesky-comments or spinning up separate extensions (hence maybe a switch to quarto-bluesky naming).

For the additional features mentioned:

• Feed display: We can use app.bsky.feed.getAuthorFeed
• Hashtag filtering: We'll leverage app.bsky.feed.searchPosts
• Post embedding: We can wrap the existing library from BlueSky Embed Post

I'm happy to integrate these either within the same extension or split them out, depending on what makes most sense architecturally. No pressure.

Lastly, if we could get the ball rolling on migrating this repository to quarto-ext that would be great. I'd like to try to decrease the number of links/link web to a spot that we're already looking at phasing out. @cderv you okay with accepting the repo under quarto-ext?

Note

I may be a bit slow to respond as I'm juggling end-of-semester teaching/research, an NIH grant review, and jet lag recovery. That said, I trust your judgment completely on implementation direction.

Resources:

• Quarto project pre-render/post-render
• Stamp Lua filter with custom placement
• Stamp Lua filter with template:
• app.bsky.feed.searchPosts API Documentation
• app.bsky.feed.getAuthorFeed API Documentation
• BlueSky Embedding Post

[gadenbuie]

Awesome, this all sounds great. And I have some good news: I've figured out how to do the atproto URI conversion in the Lua layer!

When you have a minute @coatless, can you please give me and @cderv admin access to this repo? We'll work together to migrate it to quarto-ext and to get that set up, likely tomorrow. He and I have a bit of overlap in the mornings (he's in Central European time and I'm in Eastern US).

Once we have that set up, I'll submit the changes I have ready as PR(s). I won't wait for review, but if you have any comments once you have a chance to look through the changes we can always adjust. When I've got the extension in a place where users of either older extension are supported, I'll archive my extension and point to this one.

Good luck with end-of-semester and grant review busy-ness!

[coatless]

@gadenbuie done. To emphasize, I'll be able to contribute more at the end of the week (F Sa Su). More a crunch now.

[cderv]

Really great news ! I'll move this repo.

[cderv]

Repo is now migrated in @quarto-ext and @coatless I sent you an invite for admin access on this repo, same for you @gadenbuie

Thanks a lot for accepting to this ! Really eager to see all the great feature for Bluesky integration!

I let you add the Disclaimer on the README.

[coatless]

@gadenbuie How would you like me to start contributing? Do you want me to raise issue tickets on the 3x points and, then, send a PR for each? Or just PR away?

[gadenbuie]

@coatless I'm on the fence about whether we should increase the scope of this package. I certainly see the appeal of having a one-stop extension that does all the Bluesky things. At the same time, I'd also really like to see the comments extension through.

It's hard to evaluate because I'm in the comments headspace at the moment, but I lean toward long-term maintainability. I want to be able to continue to develop and maintain the comments extension in my spare time and I worry about being able to do that at the level of quality of other extensions in quarto-ext if the scope of this extension expands.

Could we focus on the comments extension for a bit longer? I do think opening new issues is a good idea; I'll try to do this more with things I have on my mind. I'm currently working on refactoring nested comment rendering, in part to address content labelling UI/UX but also to pave the way for a few additional features I have left to port from my extension.

[coatless]

@gadenbuie let's knock out the tickets as you create them.

I'll toy around in a separate repo with ideas; we can cherry pick what we want.

Alternatively, we could do smaller targeted extensions and create a "mega"/"verse" extension that embeds extensions together.

[gadenbuie]

Another idea we're in a good position to execute: create a link blog populated from your posts on Bluesky. I'm envisioning you'd use a hashtag like #LinkBlog and we'd find posts by author and add them into post. It could be static and/or dynamic (collect posts during render, augment/update with live posts). (idea via https://bsky.app/profile/aac.social/post/3ldua5w3uws2g)

[coatless]

To make sure I'm grokking this, we're looking to incorporate a feed that specifically detects #linkblog and lists those top-level comments? From this, maybe we can pass a URI segment to display post, which will then add the comments for the post?

Something like:

https://dotat.at/:/

https://rubyflow.com/

I think at one point Yihui had something similar for blogdown posts?

[gadenbuie]

Yeah, that's right, basically, the link blog would reflect any links you share (with the #linkblog hashtag so it's opt-in and easy to find) to a running link blog page. Here's another example.

Edit: oh and I'm not formally saying we should do this, just since we started collecting some other features here it felt like a good place to record the thought.

[coatless]

@gadenbuie okidokies, I think it would be worth investigating further. I have some prototype feed code from earlier that I can try repurposing.