{ "version": "https://jsonfeed.org/version/1", "title": "rss on jocmp", "icon": "https://avatars.micro.blog/avatars/2026/14/52207.jpg", "home_page_url": "https://jocmp.com/", "feed_url": "https://jocmp.com/feed.json", "items": [ { "id": "http://jocmp.micro.blog/2025/08/22/the-guts-of-a-new/", "title": "The Guts of a New Machine", "content_html": "

ReadYou just released v0.15.0 this past week. I’ve been waiting to see their take on one very specific feature: large screen support. I tried it out. It’s great! There’s a subtle animation for article filters in the list column. There’s also an expand/collapse option to view the article in full screen. This is a new paradigm that Google has been pushing in Keep and Gmail. In the face of these improvements, I’ve been thinking to myself, why did I build Capy Reader when ReadYou has such an advanced UI?

\n

In retrospect, I set out to build Capy Reader for two reasons: exploration and compatibility. I wanted to explore how RSS readers worked under the hood, how they looked up feeds, and why they made the trade-offs they made. NetNewsWire’s technotes were a major help here since they delve into sync strategies and software architecture. Needless to say, there’s no shortage of information.

\n

I built Capy Reader for compatibility with Feedbin too. There are plenty of readers available that work with Feedbin, sure, but none of them are exactly a pleasant experience. So when I built Capy, I built it for that. From there, I thought I could skirt around the need for Feedbin sign-in credentials in Google Play’s review process by building out Local accounts. That wasn’t the case. Before I knew it, I was supporting Local accounts, Feedbin, and Google Reader (both Miniflux and FreshRSS). This was a far cry from the original, simple vision of Capy as a Feedbin-only client.

\n

This brings me back to ReadYou’s latest improvements. I’m now considering forking ReadYou and using it as the basis of Capy Reader going forward. There are a few goals I have in mind that would make this unique:

\n\n

There are two more considerations I want to highlight if I go this route. Capy Reader would be relicensed under GPLv3, and I’d also want to build any revisions in a way that could be upstreamed to ReadYou.

\n

All of this is preliminary. These are untested ruminations, and talk is easy. If you have any reasons why you use ReadYou over Capy, or Capy over ReadYou, drop me a line on Mastodon!

\n", "date_published": "2025-08-22T16:18:34-05:00", "url": "https://jocmp.com/2025/08/22/the-guts-of-a-new/", "tags": ["capyreader","rss"] }, { "id": "http://jocmp.micro.blog/2025/08/02/capy-log-open-in-browser/", "title": "Capy Log: Open In Browser, Article List Tweaks", "content_html": "

Summer in the midwest is careening towards autumn, and version 2025.08.1153 of Capy Reader is in review for the Play Store. I haven’t been adding huge feature changes lately. Instead, I’ve been trying to pick apart the app and understand some underlying jank that exists. More on that later. While there aren’t huge changes in this release, I did get around to adding “Open in browser” as an option to view articles.

\n

Open In Browser

\n

“Open in browser” by default has been a long outstanding feature. It was first requested in January of this year. I feel bad sometimes when there’s a huge delta between time requested and time implemented, but I spent a lot of time waffling on this feature.

\n

It’s deceptively simple but the “open in browser” requires two key expectations

\n
    \n
  1. The article opens in the browser
    2. \n
  2. The article is marked as read
    3. \n
\n

This second expectation prevents a direct call to an ACTION_VIEW intent since there is not a way to simultaneously launch two actions from a widget RemoteView. The trade-off then is to create a trampoline activity which first opens the app with a transparent view, and then opens the browser. The trampoline activity can be avoided when the “open in browser” action is initiated within the app since the article state is already within context.

\n

Putting it all together, the new “open in browser” feature in Capy does what it says on the tin:

\n

\n

Feed Selection UI Improvements

\n

One outstanding problem in Capy Reader has been feed list transitions. To spot the bug in previous versions:

\n
    \n
  1. Scroll part way down a page, note the status and toolbar change color
    2. \n
  2. Open the feed list and select another feed
    3. \n
  3. Jank! The previous article list will scroll - or teleport - to the first index, and then the next feed will load in
    4. \n
\n

Here’s an example of the problem at 4x speed. The top bar state jank is noticeable at the 10 second mark when it still appears as the changed color when the list has already switched to the next feed.

\n

\n

The solution I found was to rebuild the article pager in the view layer. This in turn invalidates the list state which simultaneously invalidates the scrollbar state.

\n
import androidx.paging.Pager\nimport androidx.paging.PagingConfig\n\n// In View Model\nfun buildPager(): Pager {\n    return Pager(\n        config = PagingConfig(\n            pageSize = 50,\n            prefetchDistance = 10,\n        ),\n        pagingSourceFactory = {\n            findArticles(...)\n        }\n    )\n}\n\n// Pager is now in Compose view layer\nval articles = remember(...) {\n   viewModel.buildPager(...)\n}\n

The last wrinkle with this approach is pager updates in response to in-feed actions. One example of this is swipe-to-refresh on the “Unread” filter. When the refresh finishes, articles that have been read disappear. If the invalidation flag - in this case a timestamp - is passed to the remember function then the feed will flash causing the list to flicker and jump back to the first index. Instead the solution is to track a separate variable within the view model. When the timestamp changes, the view-level articles variable is refreshed which triggers a new call to the pagingSourceFactory.

\n

Here’s a demo putting it all together:

\n

\n

Something so subtle that you might not have even noticed, but your brain did.

\n

What’s next

\n

In the next few updates I hope to add more settings around “open in browser” based on early feedback. Additionally, I have an outstanding UI tweak around the local blocklists that I really want to wrap up and deliver.

\n", "date_published": "2025-08-02T14:49:32-05:00", "url": "https://jocmp.com/2025/08/02/capy-log-open-in-browser/", "tags": ["capyreader","rss","programming"] }, { "id": "http://jocmp.micro.blog/2025/07/12/full-content-extractors-comparing-defuddle/", "title": "Full Content Extractors: Comparing Defuddle and Postlight Parser", "content_html": "

One of the hardest problems with RSS feeds is displaying full content. It’s essentially an unsolvable problem given the complexity of webpages and the lack of adherence to a semantic layout for any given blog or news site. It would be nice if each page had a header tag, and an article tag, but it’s not that simple. Full content parsers attempt to solve this, but each has their own set of trade-offs.

\n

Legacy Contenders

\n

Tools like Mozilla’s Readability.js used to solve this in the past, but given their recent woes it’s hard to trust it as a tool. Postlight Parser née Mercury Parser was a better option. Instead of trying to solve all webpages with a set of common heuristics, each domain could be overridden with a custom parser. In effect, The Verge could have a Verge-specific parser while Ars Technica could have a slightly different parser.

\n

It would be simple to stop there, but Postlight Parser was a product of its time. Around 2015, there was a push by Google to speed up the web by simplifying webpages with AMP. Postlight was one of many companies that stepped in with their own set of tools like the parser to improve development with AMP. But as time passed, AMP fell out of fashion, and Postlight was acquired by NTT Data.

\n

Postlight Parser essentially ended with the acquisition. It’s still possible to find Postlight Parser in the wild, however. Feedbin, a web-based feed reader, uses Postlight Parser to power its full content mode. Core development has ground to a halt with the last release in 2022.

\n

A New Entrant

\n

Readability.js and Postlight Parser may very well represent the past of full content extraction. However a new project called Defuddle might take their place. Defuddle was released in early 2025 by the developer behind the note-taking app Obsidian. It takes the Readability.js route of a one-size-fits-all input function with different internal heuristics.

\n

The following is a brief and non-exhaustive comparison between v2.2.3 of Postlight Parser and v0.6.4 of Defuddle using a small node.js application (source code on GitHub). Defuddle seems to work best when the site’s markup is already well formatted which is the case with The Verge. In the following review article, Defuddle picks up more images, headers, and content like the overall review score than Postlight Parser.

\n\"\"\n

Parsing fails if you throw an article from Yahoo News Singapore at either Defuddle or Postlight Parser. Defuddle has a slight edge in that it at least extracts images and article content but still captures garbage text like “ADVERTISEMENT.”

\n\"\"\n

In short, better base markup still results in a better outcome. Defuddle is clearly the project to watch given Postlight Parser’s lack of updates, and it’s backed by a live project with Obsidian. Full content parsers come and go but the need to tame the chaos of the web is never ending.

\n", "date_published": "2025-07-12T18:03:00-05:00", "url": "https://jocmp.com/2025/07/12/full-content-extractors-comparing-defuddle/", "tags": ["rss","programming","mercury parser"] } ] }