jekyll-webmention_io: Webmention send to brid.gy only triggered when syndication link inline of post

Random aside, there are other targets beyond in_reply_to that would be nice to also support: like_of, repost_of, bookmark_of, tag_of all would result in webmentions and also require properties to properly mark up.

Is there an existing issue covering that? If not, I can put together a separate PR to expand the current in_reply_of logic to handle these other cases (maybe by removing the hard coding and making it configurable).

I’m open to it. Much of the original work had been driven by my own site’s needs, but I’m happy to continue increasing the functionality.

Naming and cache invalidation… 😉

Great feedback! I have a prototype implementation put together. I’ll tweak the names and throw a PR together.

I could see using this same method for publishing to IndieNews, for example, so something along the lines of publish_endpoint–or heck, the obvious now that I think about it: syndication_endpoints–would seem to make sense.

Random aside, there are other targets beyond in_reply_to that would be nice to also support: like_of, repost_of, bookmark_of, tag_of all would result in webmentions and also require properties to properly mark up.

Is there an existing issue covering that? If not, I can put together a separate PR to expand the current in_reply_of logic to handle these other cases (maybe by removing the hard coding and making it configurable).

That’s an interesting idea, @fancypantalons. I like it, although with underscores (_) rather than hyphens (-) in the front matter key name. For the key in the config, I wonder if it might make sense to make the key something like notification_targets, publish_endpoints, or similar. The term silos doesn’t immediately indicate what that configuration option would govern. (Also: naming is hard.)

So, I think I see the issue, here, as I just ran into it myself.

Fundamentally, the issue is that the webmention gatherer is a Jekyll Generator. As per their docs, generators are run after the content for the site has been identified, but before the site has been generated.

Unless I’m mistaken, that means that “post.content” in the generator, contains the unprocessed markup, rather than the formatted output, and anything that’s in the layout file (including, say, URLs to which you want to send a webmention) doesn’t appear in the post content.

As a consequence, any Bridgy URLs in the layout are invisible to the plugin and the webmention isn’t seen.

The way the plugin deals with this use case is the “in_reply_to” post header, which generates a URI in the webmention cache. But this is only appropriate when the post is, in fact, a reply to another piece of content (a post, a tweet, etc). If you’re syndicating original content to Twitter via Bridgy, “in_reply_to” is not appropriate.

I suspect the solution is in enriching the plugin to look for other types of front matter. For example, I could imagine a solution where you have a new bit of front matter that perhaps looks like this:

syndicate-to: [ twitter, github ]

And then a bit in _config.yml:

webmentions:
    silos:
        twitter: https://brid_gy/publish/twitter
        github: https://brid.gy/publish/github

Then update the content scanner to look for the syndicate-to front matter, and if found, have it automatically gather the silo URLs in the webmention cache.

If this looks like a reasonable design, I can throw together a PR.