Fetching Responses
A few days ago, I wrote on Mastodon about problems with the IndieConnector and brid.gy.
There I mentioned that I have long been planning to fetch external replies, likes, and reposts myself. However, this is not as trivial as it seems at first glance.
Unfortunately, I haven't figured out why collecting replies via brid.gy is no longer working as it used to. I can't view the current logs because they end with error messages before a Webmention is sent.
So it is indeed time to tackle this feature and remove it from the upcoming-features list on GitHub. And that's exactly what I am doing.
When posting automatically to Mastodon or Bluesky, the IndieConnector plugin (IC) already saves the URLs to the posts. In the case of Mastodon, you can also manually provide a URL (this will also be available for Bluesky).
These are already good prerequisites for the feature, as IC knows where to look to collect reactions. Mastodon provides three endpoints to access likes, reposts, and replies – wonderful.
There are already a few solutions and descriptions of how to solve this with JavaScript. They work well, but for the plugins, I need (and want) to take the PHP route.
The IC goes through all the URLs, fetches the replies, and then sends a Webmention to itself. Each response has a virtual page with corresponding Microformats. From here, the usual Webmention process takes place. One reason I chose this approach is that this way, I only need to build the fetching mechanism and not open another path to store data, etc.
Unlike the JavaScript solution, I need to remember which reactions I have already processed so that I don't keep sending the same Webmentions and create unnecessary load on the systems. So, I store the last known response ID for each Mastodon endpoint and end the process once that ID is reached.
So far, this is working great.
However, for the past few hours, I've been sitting here wondering why these Webmentions don't want to get through. They are being sent. And as cool as I find this whole technology, debugging asynchronous processes is and remains tricky. I try to cover individual steps with unit tests, but sometimes – like right now – I still find myself staring at the screen confused.
I hope to resolve the issue quickly. Then I would have the complete process for Mastodon ready and only need to build the fetching mechanism for Bluesky (because after fetching, it continues just like it now does with Mastodon).
Update
I used an incorrect (old) URL for my Webmention endpoint and sent all Webmentions into oblivion, which is why they didn't show up in the panel 🤦🏼♂️
genau das habe ich mir in den letzten tagen gebaut. ich habe aus dieser JS lösung um antworten von mastodon zu holen
https://carlschwan.eu/2020/12/29/adding-comments-to-your-static-blog-with-mastodon/
mit hilfe von — räusper — chatgpt — eine php lösung gebaut, die mir kommentare und dann auch likes von mastodon via mastodon API holt. likes holes ich parallel auch von bluesky. noch nicht implementiert, aber das alles kann man dann auch 15 minuten oder länger von kirby cachen lassen, um die API anfragen zu reduzieren. sieht dann im ergebnis so aus:
https://wirres.net/articles/webwanderung-vom-26-04-2025/beilage
bei vielen likes und kommentaren wird’s schnell etwas crowded, aber deshalb stell ich das alles auf ne eigene meta-seite:
https://wirres.net/articles/755472081318182912/beilage
die bridgy webmentions für mentions, likes, reposts und replies sammle ich weiter ein, zeige aber nur noch die eigentlichen mentions an, die mir die mastodon und bluesky APIs ja nicht liefern können.