Yeldar Kudaibergen – proxyfeed

A deep cleanup of ProxyFeed

Yeldar Kudaibergen — Fri, 14 Nov 2025 16:00:00 PST

I realized that while improving ProxyFeed I overloaded it so much that its original purpose began to suffer: providing a stable address for a feed. So I removed almost all feed modifications. Almost, because feeds have self-tags, and those must be rewritten so the feed reader has no doubts about the canonical source of the proxy feed.

There is something interesting here: the less you interfere with someone else’s feed, the cleaner the architecture becomes. You remove one piece of logic, and immediately you see that another one is unnecessary. Then another. And step by step the system returns to its natural form. Without trying to “improve” what should not be improved.

It turns out ProxyFeed should be a stable bridge between the original feed and the platforms. That is its only strength. Everything else is noise that gets in the way.

Once I removed almost all modifications, it became clear that the true value of ProxyFeed is its reliability. That it does not break the feed. That it does not disappear. That once a stable address is created, it lives and makes it possible to change the original feed URL or even the original feed type without pain.

And here is the fascinating part: the simpler the system becomes, the clearer the real work becomes. You need to correctly identify the feed type. You need to guarantee no duplicates. You need a cache system that does not fail. You need to ensure that self-tags always point to the proxy feed. You need proper support for JSON, Atom, and whatever comes next.

Here is what was actually done:

fully removed all feed content modifications, no element edits and no attempts to "improve" the original feed;
implemented feed type detection (RSS, Atom, JSON Feed) before parsing;
kept only the essential rewriting of self-tags (rss/atom/json) so feed readers treat the proxy feed as canonical;
added a strict check preventing the same original feed from being connected twice;
added validation ensuring publicUrl is unique and never conflicts;
added proper handling of JSON Feed without trying to mimic XML;
improved XML normalization: remove BOM, add declaration only when missing;
removed itunes:new-feed-url so no player can redirect subscribers back to the original;
rewritten caching logic: correct handling of hash, unchanged, partial and ok states;
added atomic guarantees for cache and backup creation;
moved the whole project closer to the “as-is” principle: minimal interference, maximum stability.

I’m self-taught dev, and I have to learn from my own experience from trying to improve things that, as it turns out, didn’t need to be touched. That’s okay. ProxyFeed grows together with me. And every time I simplify it, I understand the architecture, the responsibility, and the path itself a little better. I want this service to live a long life, and for the people who choose it to be able to rely on it with confidence.

ProxyFeed devlog: funding tags, bug fixes

Yeldar Kudaibergen — Tue, 15 Jul 2025 17:00:00 PDT

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.

I submitted my application for the LinkedIn REACH Backend Apprenticeship and had to write three essays, so I didn’t have much time for coding. Fortunately, I got everything done and sent off — now I’m back to working on ProxyFeed.

Originally, ProxyFeed was built specifically for podcast feeds, and even now, I still find remnants of that original thinking when adding new features. But my approach has changed — I now support Podcasting 2.0 tags for any type of RSS feed, not just podcasts. That said, I’ve kept a flag in the database just in case we need to distinguish between podcast and non-podcast feeds.

One of the updates: I revised how the <podcast:funding> tag works. Now, users can only add one funding tag per feed, regardless of whether it’s a podcast. Technically, multiple tags were allowed, but there's really no point — podcast players usually display just one, and I assume RSS readers will do too. After a tag is added, the feed is immediately re-fetched so the change appears in the proxy without delay. Also, I finally implemented tag deletion, and if a feed already has a funding tag in the original source, we now inform the user on the settings page.

⚠️ This funding tag comes from the original feed and cannot be edited here. To change it, update your original RSS feed or remove the tag from the original feed — then you’ll be able to edit it here.

What happens if the original feed didn’t have a funding tag, but the user adds one through ProxyFeed — and then the original feed later adds its own funding tag? In that case, ProxyFeed keeps the original intact. The original feed always takes priority over proxy changes.

This work, even just adding a seemingly simple tag like <podcast:funding>, reminded me how complex this project really is.

Another step: replacing the atom:link with the URL of the generated proxy feed. This worked perfectly for new feeds, but didn’t apply to older ones — unless the user updated the domain or slug. So, I wrote a script that scanned all feeds and patched the outdated ones.

I also cleaned up the database — removed old unused tables. At some point, I had the idea to fully parse feeds into structured database tables and reassemble them later. But due to the huge variety in RSS formats (or maybe I just wasn’t ready for it), this approach turned out to be unrealistic. So I deleted all related tables. The database is now clean.

All of this is part of a gradual preparation for the next major step: adding Podping support.

Oh, and I fixed another bug: ProxyFeed supports both system and custom domains. When users picked a system domain, I wasn’t generating a slug for them, since system feeds used feed id. Now, regardless of domain type, every feed gets a slug.

A clearer vision for ProxyFeed

Yeldar Kudaibergen — Wed, 11 Jun 2025 17:00:00 PDT

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?

ProxyFeed — a permanent URL for any RSS feed

Yeldar Kudaibergen — Sun, 08 Jun 2025 17:00:00 PDT

TL;DR: I built ProxyFeed — a tool that gives your podcast (or any RSS feed) a permanent, stable URL, no matter how often your hosting changes. It enhances your feed with Podcasting 2.0 features, supports custom subdomains, and works for any type of RSS. I made it to solve my own problem — now it’s ready for others to use. Core features will stay free; premium options may come later.

Lately, this blog, podcast, and social channels have gone quiet — but behind the scenes, things have been moving fast. About a three months ago, I built a simple website for my podcast in Kazakh. As part of that, I had to change the RSS feed — a familiar problem in the podcasting world. If you switch podcast hosts, your feed URL changes. Sure, you can set up a 301 redirect, but even that isn’t guaranteed to work forever.

So I decided to solve this problem once and for all — at least for myself. I built a tool that takes the feed my podcast site generates and republishes it under a stable, fast, permanent link. Now, no matter how often I change hosting platforms, my public feed stays the same. On top of that, the tool can enhance the RSS feed — for example, by adding Podcasting 2.0 tags and other advanced features. I have big plans for the future.

This idea actually started years ago when I was still living in Kazakhstan. But back then, I didn’t have the knowledge, experience, or courage to follow through. It remained just a conversation. After moving to the U.S., I realized I had to make it real. I built the first version just for myself — then realized it could help other podcasters too. That’s when I gave it a name — ProxyFeed — and turned it into its own project.

Today, ProxyFeed is live and working. It’s currently powering the RSS feed for my audio blog, and everything is running smoothly. The core of the system is now clearly defined: the main product is the proxy RSS feed we create for the user. Everything else in the system — features, tools, domains — exists to support that one feed.

This architectural clarity led to one key decision: if a user doesn't provide a valid RSS feed with <enclosure> tags (a full podcast feed), they won’t be able to register. If you don’t already have a feed, ProxyFeed isn’t for you.

Having a clear definition of the system’s core made development much easier. For example, I used to treat the user’s custom subdomain and their original feed as equal. But now I see them both as secondary — just support elements for the main proxy feed we generate.

One more major update: ProxyFeed no longer works only with podcasts. Now it can handle any RSS feed. No restrictions. I initially built it from a podcasting perspective, but over time I realized users are much more diverse. For example, this blog now has its own ProxyFeed-powered RSS feed: https://feed.yeldar.org/blog

The old feed still works, for now. But if I ever move my blog to a new domain, only the ProxyFeed URL will remain stable. That’s the whole point — to ensure that your feed link never breaks, no matter what happens upstream.

One area of focus is Podcasting 2.0 support. I’ve started adding new tags, beginning with <podcast:funding>, and soon I’ll include <podcast:locked>. My initial goal is to implement the full Podcast Standards Project feature list.

Soon, I plan to share ProxyFeed with the podcasting community. If it solves your problem like it did mine — go ahead and use it. The core functionality will remain free. To be honest, I didn’t build this to make money. I built it to solve a problem I personally faced. Now I’m just sharing it with others.