I've rewritten my WordPress plugin that automatically adds support for full-history RSS/Atom feeds using the RFC5005 standard so the implementation is super simple now.
I'm feeling pretty good about it, like maybe this version wouldn't be embarrassing to show the WordPress core team and ask if it could be just a part of core instead of a plugin. Not that I've worked up the courage to actually do that yet 😅
If you have a WordPress site and want to try it out, and you don't mind troubleshooting in case I got something wrong, the plugin is here: https://github.com/jameysharp/wp-fullhistory
@jamey That sounds useful for my new homepage. A post-publication peer review site for the scientific literature and people should be able to download all CC reviews.
At his moment, however, the page does not have any posts yet, so I cannot tell you whether it works.
@VictorVenema That's a cool idea!
@VictorVenema I like RFC5005 section 4 for your application because on the one hand it lets consumers cache everything they've already fetched indefinitely, but it also provides for if old reviews get updated or deleted. So if someone wants to keep a local mirror of your journal's reviews, my plugin provides everything they need to efficiently keep their mirror fully synchronized with what you're publishing.
@jamey Exactly, there will be updates. So I had planned to add ActivityPub and I guess I still will, but it is cool this now also works for RSS, which is a great open standard many people use.
In principle also the older versions should be downloadable, so that people can see how a review changed in time. I guess not even ActivityPub does that, that is not behavior a normal user would like. So maybe I still need some download API.
@VictorVenema Hmm, yeah, I don't know a good way to represent revision history in a syndication feed. I guess I'd be tempted to, instead of using WordPress, put all the reviews in a public git repository and use a static blog generator like Jekyll to produce an HTML view of them? I dunno.
@jamey That is an interesting idea, I should learn to think like that rather than code the wheel from scratch.
But using WP saves a lot of coding, versioning is not the only feature I need.
@VictorVenema Yeah, there are lots of reasons to just use WordPress, and I don't think it'd be a mistake to do that. Static site generators for blogging have a lot of plugins and features available too though, so it still might be worth considering options like https://jekyllrb.com/ and https://gohugo.io/ to see if they meet your needs 🤷
@jamey Something else. A blog just changed its URL and my RSS reader showed the last posts again. Also when I subscribe I often get the first dozen or so posts in the reader.
Is that just a bad reader (I use Google Blogger) or is that default behavior? If the latter, sending all old posts may be a bit much and make it hard/impossible to find the recent posts of other blogs below it.
@VictorVenema According to the RSS and Atom specs, the feed's publisher is required to assign a unique ID to each post, and then never change that ID. They're allowed to change anything else about the post, including what URL is its original location, and as long as the ID doesn't change, consumers can tell that they've already seen it.
Unfortunately it's pretty common to use the post's URL as its ID, and then if the publisher changes the URL, the ID changes too, violating the spec. There isn't much consumers can do at that point.
Feed readers make this worse, though, because they save old posts they've seen even after those posts disappear from the feed. So when IDs change, you see both the old and the new copy of the same post. A full-history feed helps then because the reader can know that the posts it saw before are gone.
The full-history spec provides for paginated feeds too, so feed readers don't have to fetch any more posts than they do today unless they want to.
@jamey Thanks. Interesting. So much to learn, so little time on Earth.
So then one would expect that when an RSS reader updates to RFC5005 they will also update what they display.
@VictorVenema Also I claim that if one prolific feed can make it difficult to find posts from another feed, then the feed reader's UX is bad. Unfortunately as far as I can tell most feed readers get this wrong. It's particularly troublesome for long-form works like webcomics, serialized writing, podcasts, etc, where you need to read/listen to posts from the beginning and in the right order or they won't make sense. Which is the use case I care about most 😅
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!