Aaron Parecki

You can now subscribe to realtime updates of IndieNews feeds via WebSub! (formerly known as PubSubHubbub)

It was relatively straightforward to add the necessary tags and ping the WebSub hub to make this work. I used Switchboard as the hub. I added the <link> tags and HTTP headers to indicate the hub and self URLs. When a new post is submitted, I then ping the hub, which is just an HTTP POST request with the URL of the feed.

I then went to test the publisher using websub.rocks. That part worked great, websub.rocks was able to subscribe to my feed, and I see it receiving the ping when a new post is added to IndieNews.

Then I went to try subscribing to IndieNews in Woodwind. Woodwind reported that it subscribed successfully, but it appears that it no longer shows me the WebSub statistics that it used to. I wanted to ensure it was able to subscribe to the realtime feed, so I then used websub.rocks to test Woodwind! 

As it turns out, Woodwind failed to subscribe to the test feed in websub.rocks, but not because of a bug in Woodwind! It turns out I had a small bug in websub.rocks caused by a previous renaming of some things. It was a quick fix and I'm glad Woodwind was able to point that out!

After adding IndieNews to Woodwind, I then realized that these posts don't look quite right in readers, and we likely need to do some more brainstorming on how they should be marked up and consumed. The challenge is when displaying a bookmarked post, who should appear as the author, and where should the permalink go? To the bookmark or to the post being bookmarked? It's likely the case that you'd want to see both pieces of information, especially since you see both pieces of information on IndieNews.

Let's take a look at a post on IndieNews:

This is a post that Chris (boffosocko.com) bookmarked on his site, and submitted to IndieNews. His goal was to share the Wordpress plugin with the community, so that's the most prominent thing being displayed here. The "WordPress IndieNews" title links to the GitHub repository, and we see "github.com" below reflecting that. At the end of the line, we see "from boffosocko.com" which is a link to his bookmark post. This indicates to the viewer that this was submitted by someone else.

I am reasonably happy with the way this is presented on IndieNews. The question then is how should it appear when being viewed in a reader such as Woodwind? We clearly have more research to do in this area, so I've started by adding this screenshot and a short description to the Bookmark page on the wiki.

Today I started what is hopefully a series of updates to IndieNews. It's been a while since I've worked on it, probably because it's been mostly working fine which I guess is good.

The main thing I did today was replace its own Microformats parsing with delegating that to XRay. This should provide better results when parsing pages, since I've been concentrating my work in consuming Microformats posts in that project.

The visual update today is a change to how submitted stories are displayed. Previously, each story always showed the headline as a hyperlink to the post. For short titles, this worked fine. But sometimes someone would submit a plaintext note, or an article with a very long title. This looked pretty bad. Now, IndieNews will switch to rendering the post as a text note in a few cases. This means URLs in the note also get hyperlinked individually, which is a good improvement. 

Newlines in the text are also preserved now.

As before, if a post with a title is submitted, then no content is displayed on the site. IndieNews is not meant to be a reader, it's just meant to link out to other content.

Another thing that went live during this release is the Dutch translation, thanks to @sebsel!

So feel free to submit all your Dutch stories here! https://news.indieweb.org/nl

Oh and one more thing. You should now be able to submit stories with emoji in the name! 😎

Straightforward update today. I added a documentation page for the bookmark interface of Quill!

Not a lot to say other than that!

Today I worked on better media support. This involved a couple of changes.

• Reposting audio and video posts that show the player for the reposted media
• Support for audio + photo posts (shows as an audio player with poster image)
• Support for video + audio + photo posts (shows as the video player with a hidden audio link for mf2 consumers)
• Fallback for browsers that don't support <video> or <audio> that includes a link to download the files

Here's an example of a reposted podcast episode. It includes the episode name and an <audio> tag which plays the episode inline.

I can now also create audio posts that include an mp3 file. If the post also includes a photo, then the way it's rendered is in a <video> tag using the photo as the poster image. (ht tantek) This ends up looking essentially like a video player with a freeze frame in both Chrome and Firefox. On mobile, it looks like a video but the full-screen player that launches doesn't include the poster image.

I was unable to actually test the fallback support for when browsers don't support the <video> tag, but now I also include text that links to the video and audio files for browsers that don't render the player themselves. There is a setting in Firefox that I thought should disable the video tag (media.navigator.video.enabled), but it didn't seem to actually disable the video tag.