Yeldar Kudaibergen – qrx

QRX doesn't need HTML body

Yeldar Kudaibergen — Wed, 27 May 2026 24:00:00 GMT

It all started when I saw this error in the df console:

622|direct | [DISCOVER HTML FAILED] [http://thesecularfoxhole.live/](http://thesecularfoxhole.live/) Request failed with status code 503 (Service Unavailable): GET [https://www.thesecularfoxhole.live/](https://www.thesecularfoxhole.live/)
622|direct | [DISCOVER HTML FAILED] [https://www.thesecularfoxhole.live/](https://www.thesecularfoxhole.live/) Request failed with status code 503 (Service Unavailable): GET [https://www.thesecularfoxhole.live/](https://www.thesecularfoxhole.live/)

The strange part was that the website was fully accessible in the browser, and the auto-discovery tag was also there:

<link rel="alternate"
      type="application/rss+xml"
      title="The Secular Foxhole"
      href="https://feeds.captivate.fm/the-secular-foxhole/" />

At that moment it became clear that the problem was on our side. There were two possible explanations, and increasing the timeout immediately solved the issue. Previously it was 3 seconds, and the site simply did not have enough time to load completely. And the word "completely" is the key point here.

To extract flows from <head>, QRX does not actually need to download the entire HTML page. We only need the document until </head> or </body>.

And a check in PageSpeed Insights showed that thesecularfoxhole.live had problems specifically in "Performance".

The solution

Now QRX no longer waits for the page to fully load. (It would actually be interesting to understand why it waited in the first place. Why did we need the full page?)

As soon as we receive something like:

const HTML = [
  "</head>",
  "<body"
];

or if the entire page becomes too large while there is still no <head> ending, we stop reading. There is nothing more for QRX to discover at that point. Full HTML loading may appear later in QRX, but for now the <head> section is enough.

Meet QRX 0.8.1 "No body".

Follow podcasts directly with QRX

Yeldar Kudaibergen — Tue, 26 May 2026 24:00:00 GMT

After DirectFlow was mentioned in Podnews, I decided to explain in a bit more detail how podcast subscriptions can work now. Besides scanning a QR code or typing a website address manually, DirectFlow can already follow podcasts in several different ways.

In DirectFlow, you can already follow a podcast by:

scanning a QR code of the podcast website
pasting the website link
pasting a link to almost any page of the podcast website
typing the domain manually and pressing Enter
or using this url:

https://directflow.app/follow?url=https:// podcast website/page adresss

Soon, DirectFlow will also support following podcasts directly from links shared by podcast players and podcast apps. The important part is this: everything here revolves around the domain. Once DirectFlow receives a website link, it tries to discover the podcast flow directly from the website itself. So the website becomes:

the identity;
the connection point;
the thing you follow directly.

And this type of interaction with domains is what I call Quick response experience — QRX. It's a different way of thinking about what websites and links can do.

For podcast developers, podcast hosting platforms, and website owners: if you want DirectFlow to reliably discover your podcast, expose the RSS feed in the HTML <head> on every page of the website.

Example:

<link
  rel="alternate"
  type="application/rss+xml"
  title="Podcast RSS Feed"
  href="https://example.com/feed.xml"
/>

This allows software to discover podcast feeds directly from websites, even when someone shares a random episode page, article, or other URL from the site. Feed autodiscovery reference: https://www.rssboard.org/rss-autodiscovery

As a podcast, your RSS feed should also contain proper enclosures:

<enclosure
  url="https://example.com/episode1.mp3"
  length="12345678"
  type="audio/mpeg" />

RSS feed enclosure reference: https://www.rssboard.org/rss-specification#ltenclosuregtSubelementOfLtitemgt

Maybe podcasts were always meant to be followed this way - directly from websites themselves. The web already had most of the pieces. QRX is mostly about reconnecting them into a simpler interaction model.

DirectFlow App – follow podcasts directly

Yeldar Kudaibergen — Fri, 15 May 2026 24:00:00 GMT

I’ve been experimenting with a small project called DirectFlow.

Right now it looks like a simple podcast app, but the original idea behind it was actually much broader. At first, DirectFlow was an experiment around the idea that people should be able to follow websites directly, without depending so heavily on platforms, directories, or centralized systems in between.

The idea was simple: paste almost any website URL into a form, and the application would try to discover machine-readable flows directly from the website itself. RSS feeds, Atom feeds, JSON feeds, and other things websites already expose in their HTML metadata.

But while building it, I realized something important: most people do not naturally think in terms of “following websites directly.” It is still not a familiar user experience outside of a few technical communities.

Podcasting, however, immediately stood out as a place where this problem is very real.

Subscribing to podcasts today is still strangely complicated compared to the rest of the modern internet. Usually you need to search inside a specific app, rely on podcast directories, or manually deal with RSS feeds that normal users were never supposed to think about in the first place.

At the same time, the underlying infrastructure already exists and already works surprisingly well. Most podcast websites already expose feeds automatically. RSS already works. Open podcasting already works. The problem is mostly the user experience around it.

So I decided to intentionally narrow DirectFlow down to podcasts for now.

Today the idea is intentionally simple: you paste a podcast website URL into DirectFlow, scan a QR code, or share a link into the app — and DirectFlow automatically discovers the podcast feed and subscribes you to it.

No searching through directories.

No explaining RSS.

No copying feed URLs manually.

No platform lock-in.

Just follow the podcast directly from its website.

The current version is still very experimental, but it already supports both audio and video podcasts. If a feed contains playable audio or video enclosures, DirectFlow can detect them and play episodes directly inside the app.

At some point I also realized that my own definition of podcasting had become much simpler than many industry discussions around it. To me, a podcast is basically just an open feed with playable enclosures. That’s it. If a feed contains playable audio or video files, applications should be able to discover it, subscribe to it, and play it.

I also started using the word “flow” instead of only “feed,” because it feels broader and more correct for what I’m experimenting with. A feed is a technical format. A flow is more like a relationship between a website and an application.

Some of these ideas later evolved into another small project called QRX, which experiments with discovering machine-readable flows from normal URLs and QR codes. I wrote a bit more about that separately already.

Right now DirectFlow is mostly a place where I experiment with podcast UX ideas in public. Maybe some of these ideas eventually become part of a bigger standalone application. Maybe some of them simply help existing podcast apps become better.

Either way, I think podcast subscriptions should feel much more natural than they do today.

I’ve been working with podcasts for many years now, both technically and creatively, and one thing I’ve seen again and again is how much friction still exists around subscriptions.

I’ve had to explain RSS feeds to listeners countless times. I’ve had to explain how podcast apps work, how to copy a feed URL, where to paste it, why some apps behave differently, why searching sometimes fails, why a podcast appears on one platform but not another, and so on.

And every extra step loses people.

You can literally watch listeners disappear during the subscription process. Someone gets interested in a podcast, but before they actually subscribe, they already have to understand too many things that normal users should never have to think about. RSS feeds, directories, platform differences, search indexing, manual imports — all of this still leaks into the user experience.

That’s one of the main reasons I started building DirectFlow.

And honestly, I think I may have finally found a very simple solution to this problem.

Imagine if podcast apps like Pocket Casts, Apple Podcasts, Fountain, Overcast, or others simply added a QR scanner inside the app itself. A person scans a QR code from a podcast website, poster, video, or screen — and the app immediately discovers the podcast feed and subscribes them natively.

Or imagine someone simply pasting a podcast website URL into a podcast app, and the app instantly showing the podcast page and follow button automatically, without requiring the user to understand RSS at all. That changes the entire subscription experience.

The really interesting part is that subscriptions would finally happen directly through the podcast’s actual open feed itself, instead of depending entirely on platform-specific IDs, internal databases, or centralized discovery systems.

The infrastructure already exists. Most podcast websites already expose their feeds publicly. Applications simply need to discover and use them more naturally. I think it will be very interesting to watch how podcast subscriptions evolve from here.

Podcasting has been a huge part of my life for a long time. I’ve created podcasts myself, worked with podcasters, built podcast-related tools, explained podcast infrastructure to companies and creators, and spent years thinking about how open podcasting actually works underneath the surface.

I’m even writing a book about podcasting right now because I think there are still many things about this medium that people outside the industry do not fully see yet.

That’s also why DirectFlow is not just a random experiment for me. It comes from years of seeing the same UX problems repeat over and over again, and finally trying to build a simpler approach around the infrastructure podcasting already has.

QRX means Quick response experience

Yeldar Kudaibergen — Fri, 15 May 2026 24:00:00 GMT

Right now I’m working on the idea that people should be able to follow sources directly, without platforms or intermediaries in between. And this is already possible. You can already subscribe to podcasts through DirectFlow.

Originally, I built DirectFlow so that a person could paste almost any website URL into a form, and DirectFlow would immediately discover the main flow of that site and subscribe to it. I started using the word “flow” because it felt broader than just “feed.” A feed is more of a technical format. A flow can also represent other machine-readable relationships.

At some point I started thinking: what if a user simply scanned a website QR code, and DirectFlow instantly subscribed them to it? After all, DirectFlow already discovers the main flow of a website just from its URL. The system does not really care how that URL arrives - whether it was pasted into a form, shared from another app, typed manually, or... scanned from a QR code. That was the moment everything clicked.

I realized I had accidentally solved one of the fundamental UX problems of podcasting: subscription. Suddenly, subscribing to a podcast could become as natural and lightweight as following someone on social media for the first time.

Then I started looking around to see who else was thinking about QR codes this way. There were hints of similar ideas, but almost all of them had the same limitation: a QR code always triggered one fixed interpretation or one predefined action.

In my case, the QR code itself stayed completely unchanged, but what applications could discover from it was no longer limited. If a website exposes machine-readable flows in its HTML head or HTTP headers, then different applications can discover completely different things from the exact same URL.

For example, https://example.com may expose a podcast RSS feed in its head metadata. If a podcast player scans that website QR code, it can automatically discover the feed and immediately offer the user a native “Follow podcast” experience. This scenario already works in DirectFlow using the QRX JavaScript SDK. That was the moment QRX became a separate project outside of DirectFlow.

About the name. At first, the working name was QR-UX, because this idea is really about changing the user experience around QR codes without changing the QR code itself or the existing web infrastructure behind it. The QR code, the URL, and the website all stay the same. What changes is the experience applications can provide after scanning. Later the name became QRX. And eventually I realized it could naturally stand for Quick Response Experience, because that is exactly what this approach changes: the experience of interacting with QR codes and URLs.

I’ll continue writing about QRX here. Over the last week I’ve accumulated quite a lot of thoughts, observations, and already a bit of real implementation experience.