As far as I can tell, it works great, but I’m also not going to actually merge this to master or push it to production. Read on to see why!

When I started Publ, it was with the very specific goal of providing the publishing mechanism for a content store. Given content files and templates, format them into reasonable web-friendly HTML and Atom and whatever else the templates do, in a basically-stateless manner, and do a great job of providing high-quality image renditions and generated CSS and so on, while also supporting things like legacy URL mapping and automatic redirection and so on.

Basically, be like a static publishing system, but dynamic.

I want Publ to be the publishing and formatting part of an open, dynamic, independent web. I do truly believe in the IndieWeb mission, and absolutely want to see it become successful! However, I feel like Publ’s role is best served as one of many interlocking parts to make this work.

Supporting Webmention correctly means having the following:

• Automatically send out Webmention pings based on content changing
• Automatically receive and handle Webmention pings as they come in
• Provide structured metadata about the page content so that pings get credibly formatted on the receipient’s end

It also has a few other fun implications, like:

• Have a canonical URL for the content, generated by the publishing system itself, regardless of how the incoming traffic is routed to it
• Send updates as often as things change, but no more often than that
• Keep track of updates being sent (rather than just spamming everyone else with spurious updates)
• Generally, be stateful

And being stateful is a thing that flies in the face of the overall Publ design.

(So is the canonical URL thing, for reasons not worth getting into here, but briefly, things like staging/local/debug instances vs. the final production endpoint with any number of domain name normalizations and selections of protocol and so on. It’s messy and not something that’s easy to configure, and is impossible to detect in a way that’s consistent with what the outside world sees.)

The way I see it, this stuff is better left to external tools. Publ is for managing and formatting content. There are plenty of other tools that can be integrated into Publ templates to provide IndieWeb functionality in the way that seems most fitting to the person running the site.

For receiving WebMentions you can use webmention.io or brid.gy or this Disqus-like webmention endpoint thingamajig that’s currently in early alpha. For sending WebMentions you can use Telegraph or webmention-tools or ronkyuu or any number of other tools for sending mentions out. All of the configuration for the inbound webmentions, and for your semantic markup on your templates and so on, belongs in your templates, for what you think makes the most sense for your setup. There is no reason for it to actually be integrated into Publ.

A similar story exists for WebSub. Publ doesn’t know – nor should it have to know – what templates correspond to RSS or Atom feeds. It doesn’t know (or want to know) which of those feeds are affected by which category posts. It shouldn’t have to be configured with any mappings for which categories trigger which templates' updates, or which hub(s) those updates should be published to.

These are all better served by external tools that you, the publisher, configures to work the way you want them to.

So my proposal for supporting this stuff:

• Have a cron job that checks your feeds to see if they’ve updated
• When they do, run the appropriate tools to do the job of sending out notifications

To this end, I might start a separate project that lets you set up these mappings yourself, to be run as a sort of controller thing. It wouldn’t be at all integrated into Publ; indeed, it would work with any CMS that exports a feed or whatever. It would be configured with the following:

• One or more feeds to check
• Various plugins/actions to perform on those feeds

For example, a site’s master feed would have a WebMention task which would go through every entry in the feed, and does the following:

1. Fetch every referenced item
2. If the item has changed, parse it for all <a href> elements and send WebMentions

And they could also have a WebSub task which would simply:

1. See if the feed has changed
2. If so, send a WebSub notification to the hub of your choice

These tools can be simple and elegant and work universally across all of your sites, not just Publ ones! Got a Wordpress site? This will work with it! Got a Tumblr site? This will work with it! Got a YouTube channel? This will work with it.

And in the Publ case this also settles the canonical URL issue because it’s based on what the external tool sees, which is what the rest of the Internet should see – not based on whatever whimsical, fragile, momentary state might be the case due to it running on localhost:5000 or your private firewalled staging/preflight instance or whatever.

And this also gets along perfectly with another notion I had going into this – having services to syndicate content into a Publ site by reformatting an external Atom feed into an entry, for example. Want to automatically post all your Flickr items to a gallery on your Publ site? Use their Atom API. And the very same kind of simple tool can, for example, re-post your itch.io devlogs or your Tumblr reblogs or your YouTube videos or whatever.

I am entirely a fan of small tools doing simple things, and composing tools together. The world of CMSes already has too many Swiss army knives. Let’s keep our tools simple, doing a few things well, and have them work together with other tools.

I will absolutely have Publ support Webmention and WebSub and so on, in the best way possible – by doing nothing, and not getting in the way of other tools that can do it better.

Publ is a puzzle piece, not a complete solution.

However, there was a huge monkey wrench thrown into things when I switched my site’s configuration over to Passenger; despite all of my configuration being exactly the same between publ.beesbuzz.biz and beesbuzz.biz, the rendition cache on beesbuzz.biz was getting its permissions set wrong, and there was some rather weird behavior with how it was making the temporary files to begin with.

In investigating this I attempted to upgrade my packages on publ.beesbuzz.biz, and all h*ck broke loose.

Basically, Dreamhost, being shared hosting, is in the business of overselling capacity. They used to do a very good job of managing their capacity. But then things like WordPress happened, and more sites got bigger and more complex and started taking way more memory, and for whatever reason Dreamhost decided that they would shift towards only supporting sites built in WordPress (or basic static hosting), and then they started getting increasingly more aggressive about their “procwatch” process-killer, and somewhere along the line it reached a tipping point where now you can’t even run pipenv install without tripping their process monitoring.

I must have just been at the knife’s edge of that with publ.beesbuzz.biz, because spinning up a second Publ app was too much for it to handle.

So, for now, I’ve rolled beesbuzz.biz back to my old MovableType-based site, I have made the Heroku instance of publ.beesbuzz.biz the official one (if you are reading this then great, DNS has propagated!), and I am going to look into deploying Publ on my LiNode VPS, which it turns out has way more capacity than I’m using (thanks to them having given me incremental upgrades over the 6.5 years I’ve been with them) and which should be just fine for this purpose.

UPDATE: I have now deployed the new beesbuzz.biz on my LiNode VPS and it went off without a hitch, although DNS is probably going to take a while to propagate. Configuration is a bit fiddly though, and I’d really like this to be easy for non-server-experts to do!

In the long run I’m going to move my stuff away from Dreamhost, because beesbuzz.biz was my last major site running there and at this point I’m basically paying $7/month for mediocre DNS service.

So, while setting things up on LiNode is going to be more difficult, that is what I’ll be going with for now (mostly because my LiNode plan just renewed like a month ago so I have two more years prepaid anyway).

In the longer term I’m going to look at other webhosts; WebFaction looks pretty good, for example, and they come highly-recommended in the Python developer community. And their pricing is quite competitive!

Anyway, getting Flask running on gunicorn with an Apache reverse proxy was fairly straightforward. It’s not the simplest thing to get going but at least I have a working site (modulo DNS caching, anyway). Hopefully I can get my SSL sorted out soon too.