Yeldar Kudaibergen – directflow

What is .flow?

Yeldar Kudaibergen — Thu, 09 Jul 2026 17:00:00 PDT

I didn't wake up one morning and decide the web needed another .f format. I was building DirectFlow to let people follow websites directly, bypassing whatever subscription system a platform decided to enforce. Then I built QRX to inspect URLs and QR codes and discover the interaction endpoints behind them—RSS feeds, podcasts, YouTube channels, social profiles, emails, APIs, calendars, and everything else an object might expose. That's when the real problem became impossible to ignore: QRX could discover all of this, but every application still had to invent its own internal representation of the result. The protocols already existed. RSS knew how to be RSS. Email knew how to be email. Git knew how to be Git. WebSocket knew how to be WebSocket. The technology wasn't missing. The directory was. What the web never got was one simple, universal way for an object to publish all of its interaction endpoints together. That missing primitive became .flow.

Let's be very clear about what a Flow is. It isn't a feed, an API, an identity profile, a taxonomy, or another bloated metadata schema trying to describe the world. It is a published description of the ways an object can be interacted with. A Flow points to feeds, APIs, social accounts, messaging endpoints, repositories, calendars, payment addresses, or anything else an application understands. It answers exactly one question: How can I interact with this object? A person, a website, a company, a podcast, a repository, a product, or a service can have one. Flow doesn't need to know what the object is. It doesn't define protocols, replace standards, or impose behavior. It simply exposes the interaction endpoints that already exist.

A typical Flow is laughably simple:

# FLOW
https://feed.example.com/blog
https://feed.example.com/podcast
https://youtube.com/@example
https://github.com/example
https://bsky.app/profile/example.com
https://mastodon.social/@example
https://x.com/example
https://linkedin.com/in/example
https://calendar.example.com/events.ics
https://api.example.com
wss://events.example.com
mailto:hello@example.com
tel:+15551234567
sms:+15551234567
geo:34.0522,-118.2437
bitcoin:bc1q...

That's it. Everything behind those endpoints remains exactly what it already is. Flow doesn't replace existing technologies; it makes them discoverable from one place. The web spent decades inventing brilliant ways to publish, subscribe, message, call, clone, stream, pay, and connect, only to scatter those endpoints across HTML, footers, profile pages, documentation, QR codes, and proprietary platforms. Flow puts the map back with the object. A Flow doesn't even have to live in a .flow file—a file is simply one possible representation, and the first public Flow already lives at https://yeldar.org/flow. The same information can be exposed through HTML metadata, a /.well-known/ endpoint, HTTP headers, DNS records, or any other discovery mechanism an application understands. The transport isn't the standard. The standard is making interaction endpoints available in a predictable, machine-readable form. If Flow reminds you of something that already exists, OPML is the closest comparison. Both are machine-readable collections of endpoints. The difference is that OPML was designed to organize lists—primarily RSS feeds. Flow is not a list of feeds; it is a directory of interaction endpoints, regardless of protocol, platform, or purpose. RSS can be part of a Flow, but so can an API, a WebSocket endpoint, a Git repository, a phone number, or something that doesn't even exist yet.

Flow doesn't belong to DirectFlow. DirectFlow simply happens to understand Flow, and it can generate one from almost anything it discovers. That's the point. Flow is an open format that any application can publish, read, generate, extend, or interpret however it wants. As proof of that, I built one of the simplest possible Flow applications: a Flow Reader. Give it nothing more than the URL of a Flow, and it discovers every RSS or Atom feed inside, fetches their contents, merges every item into a single chronological timeline, and presents them as one stream. It doesn't know anything about DirectFlow. It doesn't store subscriptions, maintain a database, or require an account. It simply consumes a Flow and decides what to do with it. The same Flow could just as easily power a podcast application that automatically subscribes to every feed it finds, a browser that exposes every available interaction for a website, an AI agent that instantly discovers communication endpoints without scraping HTML, or a search engine that indexes interaction endpoints instead of trying to infer them. Each application is free to interpret the same Flow differently because Flow describes interaction endpoints, not behavior. Tomorrow, someone will build something completely different on top of Flow. Because that's the whole idea. Flow isn't a product, a platform, or even necessarily a file. It is simply a common, machine-readable way for an object to publish how the rest of the world can interact with it. A Flow belongs to the object it describes, not the application that happens to read it.

The ideas don't stop here. This is only a small part of what I've been building and thinking about. There are many more pieces that haven't been published yet, more experiments, more protocols, and more applications built on the same foundation. Right now, though, most of my days are spent driving people around Los Angeles. Progress happens between airport pickups, late-night rides, and the hours I can steal for building. Flow is simply the first part that's ready to leave my laptop and become part of the web.

DirectFlow is not just 'another' notification service

Yeldar Kudaibergen — Sun, 05 Jul 2026 17:00:00 PDT

A domain should not only open a website.

That sentence sounds small, but it contains most of what I am trying to build. Today, when someone enters a domain into a browser, the expected result is simple: the browser opens the site. The domain resolves, the server responds, and index.html becomes the public face of whatever lives there. This is normal. This is useful. But it is also incomplete.

A domain can represent more than a homepage. It can represent a person, a company, a publication, a podcast, a community, a product, a project, a movement, or an entire public presence spread across many platforms. The website may be only one surface. The actual thing people care about may live across YouTube, Instagram, RSS, podcasts, newsletters, GitHub, calendars, messaging channels, and platforms that do not exist yet.

The web already contains many of these signals. They are just scattered. DirectFlow is an attempt to make them followable.

A notification service starts when there is already something to send. DirectFlow starts earlier. It asks: what is the user actually trying to follow? Which sources belong together? Which changes matter? Who controls the source? Where should the resulting signal be delivered?

The important object is not the platform account.

The important object is the flow.

The Existing Model

Most platforms still operate under the same basic assumption:

Creator
  ↓
Platform
    ↓
Followers

A YouTube subscription belongs to YouTube. An Instagram follow belongs to Instagram. A podcast subscription belongs to a podcast app. A newsletter subscription belongs to an email provider. Every platform creates its own version of the relationship, and the audience is expected to repeat the same administrative action again and again.

Follow me here. Subscribe there. Join this list. Turn on notifications. Add the podcast. Follow the backup account. Join the Telegram. Watch the website. Check the calendar.

That is not a clean relationship. That is repeated manual reconstruction.

Platforms can host content. They can distribute content. They can recommend content. They can monetize content. They can be useful and important. But none of that automatically means the relationship itself should belong to the platform.

A creator’s public presence is bigger than any one platform.

A subscriber’s intent is also bigger than any one platform.

The Flow

DirectFlow treats the relationship differently:

Creator
    ↓
  Flow
      ↓
   Subscriber
        ↓
      Delivery

A flow is not just a list of links. A flow is a living declaration of the sources that belong together and the updates that can be followed from them.

A creator may have a website, blog feed, podcast feed, YouTube channel, Instagram profile, newsletter, GitHub repository, Telegram channel, calendar, and future sources that do not exist yet. Today, those things are usually presented as a static list. DirectFlow treats them as one followable structure.

Website
RSS
Podcast
YouTube
Instagram
Newsletter
GitHub
Calendar
Future channels

The user should not have to follow the same creator separately on every platform just to preserve one relationship. The user should be able to follow the flow once, choose which sources matter, and decide where updates should arrive.

That is the distinction.

A static bio link shows where a creator exists.

A flow shows what is alive and how to receive it.

A simple example is this:

https://yeldar.org/flow

That can be a public declaration of where my active surfaces are. Blog, podcast, social profiles, feeds, channels, and anything else that belongs to my public presence. A human can read it. A system can read it. DirectFlow can read it. An AI assistant can read it. A user can create one manually. A creator can publish one officially.

That is the direction.

Discovery should not depend on one door

The first source does not need to be a domain.

A creator may claim a domain, a YouTube channel, an RSS feed, a podcast, an Instagram profile, a newsletter, a repository, or another public source. Each claim proves control over one part of the creator’s presence. Those claimed sources can then be attached to one flow.

Claim source
    ↓
Attach to flow
      ↓
Make the flow followable

A domain is still special because it is often the strongest public identity anchor. It is portable. It is owned outside the platform. It can declare the flow directly. But it should not be the only door.

A YouTube channel can open the same flow.

A podcast feed can open the same flow.

An Instagram profile can open the same flow.

A domain can open the same flow.

The user may enter from anywhere, but the destination is the relationship behind the source.

This matters because people do not always start from the canonical place. Someone may find a creator through a YouTube video. Someone else may discover them through a podcast episode. Someone else may enter a domain. Someone else may scan a QR code. DirectFlow should be able to start from any of those surfaces and ask: what larger flow does this source belong to?

Flow as a Web Object

The web already has defaults.

/
  opens the website

/robots.txt
  gives crawler instructions

/sitemap.xml
  describes discoverable pages

/.well-known/
  exposes known resources for specific purposes

A flow can become another declared web object.

/flow
/.well-known/flow.json

The purpose is simple:

This is what belongs to this public presence.
This is what can be followed.
This is where updates can be found.

But the flow does not have to exist only as a separate file. It can also be assembled from the page itself. A website already exposes useful signals inside <head>: RSS links, alternate feeds, canonical URLs, Open Graph metadata, profile links, WebSub hubs, JSON-LD, verification tags, and other declarations. DirectFlow can read those signals and construct a partial flow even before the creator publishes an official one.

That creates three practical paths.

DirectFlow can discover a flow automatically from <head>.

A user can suggest or assemble a flow manually.

A creator can publish and claim the official flow.

Those paths do not conflict. They reinforce each other. Automatic discovery gives the first useful result. User suggestions create demand and fill gaps. Creator ownership turns the flow into an authoritative public object.

DirectFlow does not need to move content

DirectFlow should not become another place where creators are forced to publish.

It does not need to mirror videos. It does not need to copy posts. It does not need to host podcasts. It does not need to become another container for the same work.

The content stays where the creator chose to publish it.

DirectFlow only needs to answer a narrower question:

Has something changed?

If the answer is yes, DirectFlow delivers the signal to the subscriber.

That is why the architecture matters. DirectFlow can watch RSS, YouTube feeds, WebSub notifications, podcast feeds, websites, newsletters, webhooks, calendars, and other sources. But the content itself remains at the source. The creator keeps publishing where they already publish. The subscriber receives updates according to their own rules.

DirectFlow does not replace the source.

It preserves the relationship across sources.

Delivery belongs to the Subscriber

The creator should not have to decide how every subscriber receives updates.

The platform should not control that either.

One subscriber may want Telegram. Another may prefer email. Another may want WhatsApp. Another may want RSS. Another may want a daily summary. Another may want a webhook. Another may want no instant messages at all.

That choice belongs to the subscriber.

Flow
  ↓
User rules
  ↓
Delivery channel

This is why DirectFlow is not merely a feed reader, a bio-link page, or a messaging bot. It can consume protocols. It can emit protocols. It can route events between them.

RSS in        → Telegram out
YouTube in    → WeChat
Podcast in    → WhatsApp out
Website in    → Email out
Webhook in    → Calendar out

The specific protocol is not the center.

The user’s routing intent is.

This also explains why notification is only the first visible layer. The deeper product is not “send me a message.” The deeper product is “let me decide how I stay connected to this public presence.”

Creators get a new surface

For creators, the first practical product is simple:

Claim your flow.
Add your sources.
Let people follow you once.
Deliver updates anywhere.

That is the creator-facing version of DirectFlow.

It is a living follow page. Not a static list of links. Not another platform profile. Not another audience silo.

A creator can keep publishing everywhere and still give the audience one clean way to stay connected. When the creator adds a new channel, the flow can show it. When a source breaks, the flow can show it. When new updates appear, subscribers can receive them through the channels they selected.

This is especially important for independent creators, podcasters, writers, developers, educators, local communities, and small companies. Their presence is often distributed by necessity. The website is one piece. YouTube is another. The podcast feed is another. Social platforms are another. Email is another.

DirectFlow gives that distributed presence a structure.

Users can help map flows

Not every flow will be official on day one.

If a user enters a domain or source that DirectFlow does not understand yet, that should not be a dead end. DirectFlow can still create a pending flow. The user can follow it. The user can suggest a known source. DirectFlow can keep looking.

We do not know this flow yet.
You can follow it now.
You can suggest a channel if you know one.
We will keep looking.

Those suggestions are not authority. They are clues.

A creator can later claim the flow, confirm the correct sources, remove wrong ones, and turn scattered public signals into an official structure.

In that model, users create demand.

Creators confirm authority.

DirectFlow connects the two.

AI is only one participant

AI fits into this model, but it is not the center of it.

An AI assistant may discover an event, classify it, summarize it, or decide that the user should know about it. But the assistant should not need to invent a separate notification system for every use case.

It can publish an event into the same flow infrastructure.

Just like a website.

Just like a podcast feed.

Just like a repository.

Just like a monitoring system.

AI becomes another participant in the flow, not the owner of the relationship.

This is important because AI is very good at interpretation, but long-term user relationships should not depend on one assistant, one chat, or one platform. If something matters enough to follow, it should be representable outside the assistant. It should become part of a flow.

The Actual Question

The question is not only:

How should notifications work?

That is the operational question.

The deeper question is:

Where should the follow relationship live?

If it lives inside one platform, it is limited by that platform.

If it lives inside one application, it is limited by that application.

If it lives inside the flow, then platforms become sources, applications become interfaces, and delivery becomes a user choice.

That is the shift DirectFlow is exploring.

A domain can open a website.

A source can open a flow.

A flow can preserve the relationship behind the source.

And once that relationship is independent of any single platform, notification is no longer the product.

Notification is just the first visible proof that the relationship exists.

Notifications and Subscriptions belong to Users

Yeldar Kudaibergen — Sat, 04 Jul 2026 17:00:00 PDT

I honestly don’t remember exactly how many days have passed since the last time I wrote code for DirectFlow. For now, it is not my main job. As a newly arrived immigrant in the U.S., I currently make money driving for Uber/Lyft. And honestly, I wouldn’t be surprised if you happened to be one of my many passengers.

There are a lot of ideas around DirectFlow now. They need to be not only discussed, but gradually turned into working code.

Because of the pause, I noticed that I had gotten a little out of the habit of programming. But after I finally confirmed that the main idea is technically possible, something inside me switched. I decided to start with podcasting, because that is where this idea can be demonstrated most clearly. The same approach, though, can work just as well with other kinds of apps too.

The main idea is this: a subscription does not have to live only inside the app where a person consumes content. The author can publish wherever and however they want, and the audience should be able to receive updates where, how, and when it is convenient for them.

Again: DirectFlow does not take the content. It works with the layer of subscription, signal, and delivery.

Podcasts show this very well. Different podcast apps are often just different interfaces to the same content. You can listen to the same episode on the podcast’s website, in Apple Podcasts, Spotify, Overcast, Fountain, or anywhere else. That means the podcast subscription itself does not necessarily have to be stored in the same place where the person listens to it.

And what turned out to be even more interesting to me is that the same thing applies to notifications.

Why should notifications live only inside a specific app or website? Why can’t you set your preferences once and receive updates from different sources in the channel that is convenient for you? For example, some in Telegram, some in WhatsApp, some by email, some through SMS, some through MCP or another interface. Even on paper, if that is more convenient for someone.

DirectFlow does not forbid native subscriptions and notifications. It simply adds another layer: subscriptions and notifications can exist on the user’s side. The user decides what to subscribe to, where to receive updates, and in what form.

And the most important thing: this is no longer a theoretical model, but a working product.

In its simplest form, DirectFlow has two main entities: a source and a delivery channel.

A source is a website, podcast, YouTube channel, blog, email newsletter, app, or basically any object where something new can appear.

A delivery channel is the place where the user wants to receive the signal. It can be Telegram, WhatsApp, email, SMS, push, calendar, MCP, or something else.

To describe a source, I started using a flow file. Inside it, you can list different channels where the same author, website, or project publishes updates.

# FLOW

https://feed.yeldar.org/blog
https://feed.yeldar.org/podcast
https://bsky.app/profile/yeldar.org
https://linkedin.com/in/yeldar
https://www.instagram.com/yeldarx/
https://www.threads.com/@yeldarx

So a source can publish in several places at once, and DirectFlow can track those channels and deliver updates to the user wherever they choose: Telegram, WhatsApp, email, SMS, or another channel.

At the same time, a flow file does not always have to be created manually. QRX can help recognize the source and assemble that file. Often, everything needed is already in the HTML of the page itself, more specifically inside the <head>.

At the current stage, DirectFlow simply notifies the user when something new appears from a source: a post, episode, video, email, event, or another signal.

And here, it is not only delivery that matters, but also the precision of the notification itself. The user should not subscribe to abstract “notifications,” but to a clear signal with a precise name. Then the source gives the user exactly what the user chose.

I plan to make the project’s code private, but open to people who are genuinely interested in the idea. If someone suggests improvements, I will be happy to accept them. I know for sure that there are people who write code better than I do. But for me, right now, the important thing is not to prove whose code is better, but to preserve the meaning of the idea.

The idea of DirectFlow is already fairly coherent, but I still have not found its final version. The further I abstract it, the stronger it becomes.

I even tried to “break” it with AI, but every time it turned out the opposite way: AI does not so much destroy this idea as it starts to look like one of DirectFlow’s possible users. And AI can be both a source and a delivery channel.

At some point, that surprised me. DirectFlow can use AI as a tool, but DirectFlow itself does not have to depend on AI. It can exist and work entirely without it.

When AI needs to send a notification to a user, it will be easier for it to use an existing delivery layer than to create that layer from scratch. And the user will not have to configure their preferences all over again in every new app, service, or interface.

Then an even more interesting part begins: the user’s subscriptions can become not only a notification channel, but also trusted context for AI. With the user’s permission, DirectFlow will be able to show what sources the person is subscribed to, which signals matter, what exactly was used for an answer, and how it influenced the result. But that is already a separate big topic that I cannot stop thinking about.

The project will definitely have an external API and MCP. That means any website, app, author, or source will be able to connect DirectFlow on their side. Users will be able to receive notifications wherever it is convenient for them, and the source itself will be able to get rid of part of the infrastructure burden.

Ideally, the source will only need to send one signal, and DirectFlow will deliver it to where it needs to go, in the form in which the user wants to receive it.

I even expect podcast apps, blogging platforms, and other services to appear that use DirectFlow as an external layer for subscriptions and notifications.

Today I did a major refactor of the DirectFlow code and added a lot of tests. Now I need to go out and drive rideshare. I really want to spend more time on this project, and I will try to write code every day: improve the core, add new sources, and add new delivery channels.

What sources would you want to subscribe to? And where would you want to receive updates?

We have reached the point where subscriptions and notifications can technically be just as convenient as they are inside centralized apps, while still belonging to users, not platforms.

The ⊕ Direct Follow button might actually work on any website

Yeldar Kudaibergen — Sun, 07 Jun 2026 17:00:00 PDT

A few weeks ago, I wrote that the Follow button on a website should perhaps behave not as an action, but as a signal. At the time, I described it like this:

The button will become a live interface with its own signals and actions.

I think I'm finally starting to understand what I meant. Most Follow buttons on the web work roughly the same way:

Click the button.
Leave the website.
Open another platform.
Follow the source there.

This creates a strange situation. We say that we follow a website, a creator, or a project, but in reality we follow the platform through which that source is distributed. That is why I keep coming back to the idea of Direct Follow.

Not following a platform.

Not following an app.

But following the source itself.

Technically, this can be powered by many different mechanisms: RSS, podcasts, social networks, website monitoring, and many others. But the user shouldn't have to think about any of that. For the user, there is only one thing that matters: the source.

If a website is interesting, the user clicks:

⊕ Direct Follow

And from that moment on, a relationship exists between the user and the source. The word "relationship" has become the most important word in this entire idea.

In a previous post, I wrote:

The website itself becomes part of the subscription experience.

Today, I would put it even more simply. A website stops being a place that must be checked manually from time to time. It becomes a source that can be followed directly.

This week I built the first local version of Direct Follow and successfully tested the core scenario for the first time. At that moment, the idea stopped being just something on paper.

It became a working prototype. There is still a long road ahead before this becomes a complete product. But for the first time, I genuinely started to believe that subscribing to updates from any website might actually be possible.

And if this idea succeeds, the most important part of the entire system may turn out to be a single small button:

⊕ Direct Follow

Clarification about DirectFlow and QRX

Yeldar Kudaibergen — Thu, 28 May 2026 17:00:00 PDT

If I had heard about QRX for the first time on Podnews Weekly Review, I would probably have wondered why a simple RSS autodiscovery feature was being called "flow" or "DirectFlow".

'DirectFlow' is the name of the first application built on top of QRX (Quick Response Experience). The name 'QRX' came from QR codes. It was when I added QR code support to the DirectFlow app that I realized the idea was much bigger than following websites and podcasts directly. The goal of QRX is simple: let applications discover what experiences are available from a URL.

Podcasters usually don't need to do anything. Paste the website address of almost any podcast into the DirectFlow app and that's it. If the website contains a special magic link, you will successfully subscribe to the podcast. This also works with links to any page on the podcast's website. To discover a special magic link automatically, DirectFlow, through QRX, uses a technology that has existed for more than 25 years.

Soon, users will be able to subscribe not only from website URLs, but also by pasting or sharing links from podcast apps such as Apple Podcasts, Spotify, Overcast, Pocket Casts, and others.

Podcast applications don't even need to add QR code scanning to benefit from QRX. Simply allow users to paste a website URL into the search box and automatically discover RSS feeds from the page's <head> section, exactly as the DirectFlow app does today. Or simply allow users to share a website URL directly into the application.

About flows. As I continued working on QRX, RSS became just one possible result among many. Since <head> contains other machine-readable signals as well, I started using the word "flow" instead of "feed". In the DirectFlow app, a feed is one type of flow.

So QRX is the method. The DirectFlow app is the first application built on top of it. I believe the DirectFlow app solved a podcast subscription problem, both technically and practically. But it is not limited to podcasts.

I'm curious to see what the podcast industry does with this idea. From my side, I'm open to any conversations, feedback, partnerships, or experiments around it.

( Direct follow ⊕ )

Yeldar Kudaibergen — Tue, 26 May 2026 17:00:00 PDT

The 'follow' button on the web probably should behave like a signal. Most buttons today work like this:

click
leave the website
open another app/platform
maybe subscribe there
maybe come back

But what if following worked more like a connection state? So I started experimenting with a DirectFlow button ⊕ on my Kazakh language podcast website. Right now the button is in its simplest form:

After clicking the button, you are taken to the DirectFlow homepage, which immediately follows the podcast for you. But in the future, it will work like this:

Initial state:

Direct follow ⊕

After click:

Following...

Then:

Followed · View

No “open another app/platform” step. And finally, the stable connected state:

DirectFlow ✓

When you hover over it:

Unfollow · View

The website no longer feels separated from the web, where you can only follow it through some centralized app. The website itself becomes part of the subscription experience. The button will become a live interface with its own signals and actions. Like it becomes a tiny status widget representing the relationship between the user and the website.

The button dynamically uses the current page URL. Every time you click it, df will check all available flows on the website, follow the first one, and show other available options, like a comments flow. This will work on every page - at least that’s the idea for now. It means now the page itself becomes the subscription target. I think this is a very different mental model from the current web.

I would already like to add this button to this website, but the RSS feed here doesn’t contain enclosures yet, and as I mentioned earlier, df currently supports only those kinds of flows.

Follow podcasts directly with QRX

Yeldar Kudaibergen — Mon, 25 May 2026 17:00:00 PDT

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 — Thu, 14 May 2026 17:00:00 PDT

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 — Thu, 14 May 2026 17:00:00 PDT

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.

Learn programming through undestanding

Yeldar Kudaibergen — Sat, 09 May 2026 17:00:00 PDT

Sometimes I think about writing a blog post and then suddenly it feels like: “this is so banal”, “who would even care about this, let alone find it useful.” But still, let me try to explain what I’m experiencing right now in my programming journey.

It’s strange. I realized that even though I already built ProxyFeed (backend in TS), it feels like I’ve never actually programmed before. It turned out that, in my current understanding, programming is when you write code yourself and run the program to see whether it works or not. And a person becomes a programmer exactly at that moment. A professional programmer becomes one when somebody pays them for it — usually money, by agreement.

So yeah, I came up with something again. And I’m 100% going to build it. It’s one of those “projects” that simply deserves to exist, and my buddy confirmed it too. The funniest and most dramatic part is that I literally cannot not build it. So yes, in a more or less sane state of mind, I’m voluntarily getting myself into this story. Let’s see what happens.

Even though I had never written a single line of Go in my life, I decided that Go would become the main backend language for DirectFlow. I looked at the situation from many different angles and it seems that, at this moment, Go is the most suitable language for me. I even realized why. It’s strange to understand the difference between TypeScript and Go not only through syntax, but through the character, logic, explanations, and style of the language itself.

I was immediately surprised that := in Go means both creating and assigning a value. Previously, I had creation and assignment both through =, meaning one action represented two completely different things. Anyway, I liked Go because it feels like the language is built similarly to how I am as a person. I don’t fully understand it yet myself, but I like that it works.

My next realization is that we learn programming by doing it. By writing code, creating programs, and running them. Previously, it felt to me like first you learn, and only then you program. As if you cannot program until you’ve learned how. Sounds logical, right?

But here’s what I discovered: computers do not grow naturally like trees. Humans created computers, languages, and embedded their logic into them. Our job is simply to understand how things work — not memorize syntax. Then write code. Realize why it's wrong I mean error. Again and again. That’s it.

But here’s what I discovered: computers do not grow naturally like trees. Humans created computers, programming languages, and embedded their logic into them. Our job is simply to understand how things work, not memorize syntax. Then write code. See why it’s wrong, fix the error, understand it. Then write code again. Again and again. That’s what a developer’s job is, right? And apparently, this is how a person becomes a programmer. You simply write code, understand it, and when you run the program — you are a programmer.

I partially understand that the “writing code” part may sound old-fashioned now, especially when it feels like AI writes code for everyone. But this is my current understanding, and I’m sure it will evolve further. And I will definitely keep writing about it here.

Follow my blog directly on DirectFlow: https://directflow.app/follow?url=https://yeldar.org