Important update: ProxyFeed has undergone significant architectural changes. Much of the old behavior and many earlier features have been removed or redesigned. For the latest and accurate information, please read the new post describing all recent changes: A deep cleanup of ProxyFeed.

Note: This post was originally written in Kazakh. This is an expanded English translation.

ProxyFeed.io is now powering live feeds — including my own audioblog — and everything is working as expected.

The biggest difference from the previous version is that I’ve now clearly defined the main entity of ProxyFeed: the new RSS feed we generate for the user. Every function in the system revolves around this feed. Previously, I don’t think that was entirely clear to me. But this realization helped structure the entire system’s architecture.

At first, I made a big decision: Users couldn’t register unless they provided a fully valid RSS feed with <enclosure> tags. But as I kept building, my thinking evolved. I realized there’s no real reason to limit ProxyFeed to podcast feeds only — we can accept any valid RSS feed. It doesn’t have to be audio-based. If the feed is valid, ProxyFeed can work with it. This shift helped me open up new use cases I hadn’t even considered before.

It’s important to be clear about one thing: ProxyFeed is, first and foremost, a stable feed URL. Your RSS feed never changes — even if you change hosts. Everything else — Podcasting 2.0 tags, caching, feed enhancements — is built on top of that foundation.

Another core principle: If your original feed already includes advanced tags, ProxyFeed doesn’t overwrite or interfere. We only add missing tags — nothing more. That’s intentional: it keeps things simple and shows respect for your existing setup.

P.S. One thought I’ve been toying with: what if we added some Podcasting 2.0 tags to regular blog feeds?