Closing the Loop: Bluesky Reactions as Webmentions

POSSE gets my content onto Bluesky. The obvious next question: what happens when someone likes or replies to the Bluesky copy? Without a backfeed, those interactions stay on Bluesky and never reach the original post.

Bridgy closes that loop. This post walks through what Bridgy does, how setup went, and what the full cycle looks like once it’s in place.

What Bridgy does

Bridgy is a hosted service that polls social platforms for interactions on posts that link back to your site. When it finds a like, repost, or reply, it sends a webmention to your endpoint on your behalf. webmention.io receives it, stores it, and makes it available via the API.

End to end:

1. Article published at adrian-altner.de/articles/...
2. Bluesky post created with the article URL as the embed link
3. Someone likes the Bluesky post
4. Bridgy polls Bluesky, finds the like, sends a webmention to webmention.io/adrian-altner.de/webmention
5. Next deploy — the WebMentions component fetches from webmention.io, and the like appears on the article

Setup

Problem: Connecting a third-party service to a self-owned identity usually means creating yet another account. Bridgy avoids that.

Implementation: Bridgy supports login via your domain — the same IndieLogin flow used by webmention.io. Once logged in, connecting Bluesky takes one click. Bridgy reads the Bluesky profile, finds posts that contain links to the domain, and starts polling.

Solution: The default poll interval is 30 minutes. A “Poll now” button triggers an immediate scan — useful while testing the first few interactions.

What gets backfed

Bridgy sends webmentions for three interaction types:

• Likes — show as like-of in the webmention data
• Reposts — show as repost-of
• Replies — show as in-reply-to

The WebMentions component already handles all three, grouping them into separate sections. Likes and reposts render as avatar stacks; replies render as comment threads with author name and content.

Deletions propagate too

If a like or reply is deleted on Bluesky, Bridgy detects the deletion on the next poll and sends an updated webmention. webmention.io removes the entry. The next deploy reflects the removal — the avatar disappears from the like stack.

Non-obvious, but important: without this, deleted interactions would linger on the original post forever.

Notes get the same treatment

Notes are syndicated to Bluesky with the same embed structure as articles — the note URL as uri, description as post text. Bridgy picks up interactions on note posts the same way. Any like or reply on a note’s Bluesky copy comes back as a webmention to the original note URL.

The complete IndieWeb loop

With all the pieces in place, the full cycle looks like this:

Write on your site
  → deploy syndicates to Bluesky (AT Protocol)
  → Bluesky followers interact
  → Bridgy backfeeds interactions as webmentions
  → webmention.io stores them
  → next deploy renders them on the original post

The canonical URL is always mine. The interactions — wherever they happen — find their way back.

What to take away

• POSSE without backfeed is half the loop. Syndicating out without collecting reactions back means the original post stays silent while the copy gets all the engagement.
• Bridgy is zero-infrastructure. A hosted service polling every 30 minutes is cheaper than running my own AT Protocol scraper, and it uses the same IndieLogin I already rely on.
• Deletion handling matters. Backfed interactions that can’t be revoked are a feature I’d regret keeping.
• Notes and articles share the same mechanism. Any URL on the site that gets syndicated with its canonical link can receive backfed webmentions without extra work.
• The canonical URL is the anchor. As long as the Bluesky post embeds the original link, Bridgy can stitch it all back together.