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.