As part of my attempt to work on something IndieWeb every weekend, I decided to do a bit of a dive into the code for It’s known as being a (working) example of using Micropub as a means of syndication. Conventionally, people do this using Webmentions via - but I am curious about having such a system automatically add syndication back-links to my posts as well as being able to dynamically use it back-fill posts to my site (since it can do the former with potentially less magic than Webmention parsing).

I notice that in order to use, you forward the entire incoming Micropub request to the remote endpoint (we can call it ‘syndication endpoint’). This feels a bit tricky to implement because I can see it being simpler as the originating site of the request to only just send a URL of the post that needed to be syndicated - part of the appeal of Bridgy is that. But having to forward the whole thing feels interesting. But it also allows for a means of insuring that a particular syndication location only gets what it can support or what’s appropriate for that destination (bookmarks could be formatted more differently on Twitter or how reading progress is reflected).

I think I can “get” with this approach but I’m going to take a bit of a different approach. Instead of forwarding the whole body, I’m going to send it a request to update a post. Something like the following:

POST /syndication/twitter

  "action": "update",
  "url": ""

With no other arguments, this would tell the Micropub-powered syndication endpoint that it should update the provided post. Being that this one is optimized for Twitter, it could do the work of sending the tweet (or replying, or liking) and then sending a Micropub update to the original post with the change in the syndication URL. A server noticing that could use that as a way to determine that the syndication was successful with no extra need to add asynchronous processing - we get it for free.