Notifications and Subscriptions belong to Users
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/@yeldarxSo 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.
Published on July 5, 2026