administrative note | Chris Aldrich

Syndicating my IndieWeb Wiki edits to my personal website

I don’t have a specific “Edit” post kind on my website (yet!), but I’ve set things up–using a prior recipe–so that edits I make to the IndieWeb wiki are syndicated (via PESOS) to the Micropub endpoint on my website to create draft posts on my personal website!

Presently they were easiest to map to my website as bookmarks until I can create the UI to indicate edits, but changing the UI piece, and retroactively modifying some data for posts, should be fairly simple and straightforward for me.

I’m not sure I’ll keep the entire diff content in the future, but may just keep the direct text added depending on the edit and the potential context. We’ll play around and see what comes of it. It’s reasonably sure that I may not post everything publicly either, but keep it as either a draft or private post on my website. In some cases, I may just add the edit syndication link on an original bookmark, read, watch, or other post type, a pattern which I’ve done in the past for articles I’ve read/bookmarked in the past and simply syndicated manually to the wiki.

I’ll also need to tinker with how to save edits I make directly in the chat channels via Loqi, though I think that is straightforward as well, now that the “easy” part has been done.

I only wish I had thought to do this before I made the thousands of edits to the wiki earlier this week. Both IndieWebCamp West 2020 and the edits for part of organizing that were the inspiration for finally getting around to doing this.

This isn’t as slick as the process Angelo Gladding recently did a demo of and is doing to syndicate his edits to the wiki from his website using a POSSE syndication workflow, but I’ll guarantee my method was way less work!

Also, since my edits to the wiki are made as CC0 contributions, the POSSE/PESOS flow doesn’t make as much difference to me as it might on other social silos.

I don’t edit Wikipedia incredibly often, but perhaps I set that functionality up shortly too.

Here’s the first example (public) post: https://boffosocko.com/2020/06/30/55772818/

I’ll get around to fixing the remainder of the presentation and UI shortly, but it’s not a horrific first pass. It’s at least allowing me to own copies of the data I’m putting out on the Internet.

I just automated my creating stars on Github to syndicate that intent and data (by PESOS) back to my website as bookmarks. Here’s an example on my site.

This is done using a variation of Using IFTTT to syndicate (PESOS) content from social services to WordPress using Micropub.

As part of this I used the feed pattern https://github.com/{{username}}.atom to input a feed which I’m filtering with my username and the word “starred” to pull out the correct items to syndicate.

I couldn’t find a permalink URL for the star itself, so I’m adding a syndication link that points to the page of “stargazers” for the individual repo that I’m bookmarking.

While GitHub calls these stars and I might have mapped them to “likes” on my website, I’ve always thought of my intent as more of a bookmark. In practice I often use my stars as bookmarks for things I want to come back to visit on their site anyway. Since it’s my website and I have the control, I get to choose. Of course I also have the facility to create a star post kind on the site too, but the semantic difference just doesn’t warrant the work.

Now to figure out how I might extract out all of my prior data to backfill old bookmarks like this…

I’ve now got about 20 webhooks set up to pull back data out of silos like this including ones for GoodReads, GitHub, Hypothes.is, Last.fm, Spotify, Untappd, Twitter, Letterboxd, Diigo, Reading.am, Huffduffer, Google Calendar, Meetup.com, YouTube and Pocket.

Courtesy of the fantastic web magic of Ryan Barrett‘s Brid.gy and the hard work of Jamie Tanna to create the integration, I can now post my RSVPs for Meetup.com events directly on my WordPress website and syndicate (POSSE) my response to Meetup!

Hooray for open web standards and the IndieWeb! 🎉

Read Posts with Read Status via PESOS using GoodReads and Micropub

Today I accidentally realized that both the WordPress Micropub server and the Post Kinds plugin support read-status values of “to-read”, “reading”, and “finished”. I’ve managed to tweak my PESOS work flow with Goodreads.com to also include these experimental pieces using the following additional snippets of code appended to the “Body” fields I’ve described before:

&read-status=to-read
&read-status=reading
&read-status=finished

I’ve added one of the three snippets to the appropriate IFTTT.com recipes for Goodreads feeds to create the appropriate output. Here’s the first post I’ve made using the new recipe for bookmarking a book I’d like to read: https://boffosocko.com/2020/02/15/meditations-marcus-aurelius/.

Previously I’ve been using simple notes to create read posts for books and just adding a “read” category to give me more control over the data in the posts. (I only used read posts previously for online articles.) Now that I’ve got the ability to provide some better differentiation for my progress, I think I’ll switch to using read posts for all my reading (books and articles).

Incidentally following IndieBookClub.biz and Indigenous for Android which added support for these earlier today, my method may be the third to use these microformats in the wild. Thanks to gRegor Morrill, Kristof De Jaeger, David Shanske, Ryan Barrett, and Charlotte Allen for their prior work, experimentation, code, and examples for allowing me to get this working on my website.

Extra Feeds Plugin for WordPress

David Shanske has built a simple new IndieWeb friendly plugin for WordPress.

For individual posts, the Extra Feeds plugin will add code into the <header> of one’s page to provide feed readers that have built-in discovery mechanisms the ability to find the additional feeds provided by WordPress for all the tags, categories, and other custom taxonomies that appear on any given page.

Without the plugin, WordPress core will generally only provide the main feed for your site and that of your comments feed. This is fine for sites that only post a few times a day or even per week. If you’re owning more of the content you post online on your own website as part of the IndieWeb or Domain of One’s Own movements, you’ll likely want more control for the benefit of your readers.

In reality WordPress provides feeds for every tag, category, or custom taxonomy that appears on your site, it just doesn’t advertise them to feed readers or other machines unless you add them manually or via custom code or a plugin. Having this as an option can be helpful when you’re publishing dozens of posts a day and your potential readers may only want a subsection of your posting output.

In my case I have a handful of taxonomies that post hundreds to thousands of items per year, so it’s more likely someone may want a subsection of my content rather than my firehose. In fact, I just ran across a statistician yesterday who was following just my math and information theory/biology related posts. With over 7,000 individual taxonomy entries on my site you’ve got a lot of choice, so happy hunting and reading!

This plugin also includes feeds for Post Formats, Post Kinds (if you have that plugin installed), and the author feed for sites with one or more different authors.

This is useful in that now while you’re on any particular page and want to subscribe to something on that specific page, it will be much easier to find those feeds, which have always been there, but are just not easily uncovered by many feed reader work flows because they weren’t explicitly declared.

Some examples from a recent listen post on my site now let you more easily find and subscribe to:

my faux-cast:
<link rel="alternate" type="application/rss+xml" title="Chris Aldrich » listen Kind Feed" href="https://boffosocko.com/kind/listen/feed/rss/" />
the feed of items tagged with Econ Extra Credit, which I’m using to track my progress in Marketplace’s virtual book club:
<link rel="alternate" type="application/rss+xml" title="Chris Aldrich » Econ Extra Credit Tag Feed" href="https://boffosocko.com/tag/econ-extra-credit/feed/rss/" />
the feed for all posts by an author:
<link rel="alternate" type="application/rss+xml" title="Chris Aldrich » Posts by Chris Aldrich Feed" href="https://boffosocko.com/author/chrisaldrich/feed/rss/" />

For Homebrew Website Club Wednesday, even though I didn’t make it to an in-person meetup I did manage to make some reasonable visible progress on my website.

I hacked together some tweaks to add the following:

Improved support in my theme for time related microformats including dt-published and dt-updated
Because I post so frequently, I added a visible timestamp next to the date so it’s easier to follow my timeline of posts.
I removed the data for my location, weather, and syndication links from the_body of my posts and appended it to my post meta data. This should prevent it from showing up in Webmentions to others’ websites or in syndicated copies, but still be available to parsers to attach that data to my posts in readers and other services.
I modified my CSS so that the text in the Simple Location and Syndication Links plugins matches that of the rest in its section.
I added a cute little bullhorn icon in front of my Syndication Links so that it has some parallelism with the rest of the meta data on my site.
I’d always liked the idea of adding in related posts data on my site, but didn’t like how it had worked in the past. Things were even worse with replying to other people’s posts as my markup (and far too many others I’ve seen in the WordPress world) was hacky and caused the related posts data to show up in their Webmentions sent to other sites. I looked through some of Jetpack’s documentation and figured out how to remove their Related Posts functionality from the_body, where it defaults, and append it instead to the post meta section of my posts. It’s not perfect yet, but it’s much closer to how I’d like it. Best of all, that data shouldn’t show up in my replies to other sites now either! I had disabled the functionality ages ago because it made me feel like a rude-IndieWebber.

With IndieWebCamp Online 2020 coming up this weekend, I hope to fix a few outstanding issues and roll these changes up into my open sourced IndieWeb Twenty Fifteen WordPress theme as my hackday project. If you’re using it on your own site, do let me know. Not that I can promise to fix it if it’s broken in places, but I’d at least like to know how it’s working out for you or where it could be improved.

Things left over to fix:

Simple Location data still needs some CSS help to display the way I want it to.
I need to target the Simple Location icon so I can have its color match that of the other icons.
Because so many of my posts don’t have titles, I’ll need to tweak something there so that the Jetpack related posts will pick up better meta data as a pseudo-title instead of displaying the relatively context-less commentary that appears in the_body.
It may take a day or two for the related posts to populate properly, but I should make sure that it’s putting out relevant/interesting results.
Is it worth adding a default featured photo for the related posts that don’t have one? Could I pull one from other meta fields for some classes of posts?

I’ve switched over my Diigo bookmarking from posting to my website via a simple IFTTT recipe to using a Webhook in conjunction with Micropub. I quite like the results and it cuts down on some of the manual portions of the process.

I changed the theme of my website the other day, so I spent a few minutes this morning updating the microformats in it to be more IndieWeb friendly. Here’s hoping I haven’t broken anything too badly.

Annotation posts >> Highlight posts

Because they’re so similar, I’ve decided to discontinue the custom highlight posts my site had in lieu of the more prevalent annotation post kind. The layout and format of both as highlighted text quoted from another site was almost exactly the same with the primary difference being my additional commentary added to the highlighted text to call it an annotation. Conceptually I considered “highlight + commentary/reply = annotation”. The difference is marginal at best–pun intended.

Since I only had 13 highlight posts versus 121 annotation posts (plus various additional annotations and highlights which I’ve rolled up into the body of some of my read posts) over the last year and a half, I felt it seemed redundant and bothersome to maintain two separate, but nearly identical post kinds. Semantically one may think of a highlight on some text as an annotation anyway, thus the idea of annotation subsumes that of a simple highlight.

As of this evening, I’ve changed all the custom highlight posts to be of the annotation kind. Other than the one word visual difference of the post kind text changing from “highlight” to “annotation” this change won’t affect much except for those who may have been subscribed to the highlight feed. Going forward you may consider subscribing to my annotation feed instead.

I had created highlight posts first, but in the end annotation posts have won the day. And for those that don’t have them, fear not, because honestly annotation posts are really just glorified bookmarks with custom text in the context. (The glorification only entails a highligher icon instead of a bookmark icon and a bit of CSS to color the text yellow.) I do find having them delineated for my personal research purposes useful though.