As part of testing my WebSub changes for FoF, I decided to switch to a WebSub hub for myself that provides some subscriber analytics and so on. One neat thing about how WebSub works is that the “hub” layer is completely modular and it really doesn’t matter at all which one you use, and if the one you use has problems you can switch to another one just by changing the URL in your feed and all subscribers will eventually seamlessly migrate (at their next normal polling interval); if anyone even notices a problem it will just be that they don’t receive a push update during that polling interval. (Which, let’s be honest, is incredibly unlikely for most RSS feeds.)
Anyway, because of these new analytics, as well as information I gathered from my new WebSub-supporting reader, I now know a bit more about the state of WebSub.
First, the good news: a lot of web publishing providers provide WebSub. For example, the following major blogging platforms definitely have WebSub built-in:
and self-hosted WordPress can get its own built-in hub via the PuSHPress plugin.
and there is also a rich ecosystem of third-party WebSub publishing providers; for example, FeedBurner adds WebSub to all of the feeds they aggregate (although the utility of this is limited since it’s still driven by polling an external feed…), and FeedPress also provides WebSub for its analytic feed engine.
Of course, it’s also incredibly easy to add WebSub to any system with an RSS or Atom feed; first, add the following to your feed template (next to the
<link rel="hub" href="http://pubsubhubbub.superfeedr.com/" />
and then run an external tool such as Pushl (among others) to publish the updates whenever you post something new. Or, really, you could run it in a periodic cron job like I do.
(Technically this is just turning one client’s poll into a push to everyone else, which I realize is the same thing I criticized FeedBurner for above. Oh well. I mean I also have it on my site deployment hook so it also runs immediately. The cron version is mostly for the Publ site which I guess I could hack post-deploy hooks into but whatever. Anyway because of how Heroku works I can’t use Pushl’s cache if I do it there, has a few implications on performance and on WebMention correctness but I digress.)
So anyway, there’s pretty much no reason not to support WebSub as a publisher at this point, especially if you’re using WordPress (where it doesn’t come in by default but adding it is trivial).
The less-good news is that, as far as I can tell, client support is still pretty limited. Known clients which support it:
… and that’s it. Clients that people use to access my site feed but which don’t support WebSub (but should!) currently include:
FeedlyNEVER MIND! It turns out it just took a while for it to refresh its subscriptions.
- Tiny Tiny RSS
- The Dreamwidth republish engine
- Same for Livejournal
- Google FeedFetcher (which is, ironically, part of Google’s own WebSub proxy!)
And blogging/publishing providers which also semi-surprisingly do not provide WebSub include:
- Blogspot (which is weird because it’s literally Blogger, which does support WebSub! And they were acquired by Google which claims to be pro-WebSub! Despite them not using it on their fetcher proxy! Argh, Google, you’re so maddeningly nonsensical!)
- Tumblr (less surprising since their feeds are an afterthought and they’d rather people use Tumblr itself to consume content even though the UX is awful)
Most of the non-WebSub-enabled feeds I subscribe to are either hosted by one of the above, are on an un-PuSHPressified WordPress blog, or are custom-built sites that are often from folks who don’t even care about RSS in the first place.
Fortunately, syndication feeds don’t really need WebSub to be effective, but at some point I do want to build a simple federated microblogging thing around Atom, WebMention, and WebSub, mostly to prove a point. (This will probably end up as part of Subl, which I keep on talking about but havne’t written a single line of code or design doc for yet. Someday.)
Anyway. I wrote a mini-rant about why I still think RSS/Atom are better than ActivityPub for everything that matters, yes in direct response to yet another conversation on Mastodon where others were saying how ActivityPub is the future and what “everyone is using” and whatever and, no, it really isn’t. Sure, RSS/Atom aren’t as visible to a certain segment of the population but the fact of the matter is a lot of people use RSS without even realizing it, via things like:
- Apple News
- Firefox Live Bookmarks (okay I guess nobody really uses those anymore…)
- Whatever heckin' things Google uses their FeedFetcher for (and apparently a lot of people are using something from that to access my sites!)
RSS and Atom are much easier protocols to implement correctly and support, and require way less infrastructure to work, and any client can backfill the most recent entries (and supporting full content backfills is fairly simple – and yes, Publ supports that), and the data is more portable and more robust and if you want proper subscriber push it’s so easy to add on without having to deal with an entire dynamic protocol stack.
This is the hill I am probably going to die on, as it turns out.
Someday I’ll write up a ramble about possible mechanisms for supporting private/friends-only content in an Atom world (I have several ideas that have been pinging around for a long time but none are really quite satisfactory just yet, nor are any of the proposals I’ve seen floating around), because that is the one thing ActivityPub currently does which Atom/RSS can’t support easily. (There are existing mechanisms for it but they all have major downsides, like easy accidental leakage of information or a lack of client support for the authentication.) My favorite idea from a technical perspective still has a slight privacy concern and, more importantly, adds a lot of burden on the clients and publishers, so it’s probably not feasible to even try developing it. So, I dunno. The main problem always comes down to auth, and usually there’s a secondary issue of feed subscription that goes along with it.
For now my ersatz approach to private entries is to simply have Publ make an entry hidden and then I post a URL to it on a different medium where the intended recipients can see it. Which means Atom isn’t involved at all. That’s the big thing I really want to fix.
But that said, the scaling and fragility problems with ActivityPub (which are inherent to its design and not something that can be paved over by “a good standard implementation,” FFS) make me really want to work hard to re-establish RSS-style syndication as the independent web’s lingua franca.
Anyway. Old lady yells at cloud, I guess.