There aren’t as many tests on ProxyFeed yet as I’d like. I decided to run my YouTube feed through it — just to make sure everything was working as expected. But I discovered three things:

1. The feed-adding steps still need improvement.
2. I was wrong when I said that YouTube channels have an RSS feed — they don’t, they use Atom.
3. ProxyFeed only supported RSS, not Atom, as I had assumed.

The root of the problem was the rss-parser library I had chosen for ProxyFeed. My AI buddy suggested trying fast-xml-parser instead. After a quick comparison, it was obvious that fast-xml-parser works faster, more predictably, and supports namespaces properly. For now, I’ve rewritten only the feed verification part using it — the rest of the system will be migrated gradually.

ProxyFeed requires the user to insert a verification code into the latest entry of their feed, and it checks only that entry. How do we determine what the latest entry actually is? In two steps:

1. First, we sort by dates.
2. If there are no valid dates (or they’re broken), we fall back to the first item or entry in the feed.

To make this transparent, the verification page shows a direct link to the exact entry where the code should be inserted.

The bug is now fixed. Everything works (v 1.1.13). But it raised a new, architectural question: "What should ProxyFeed return as the final result?" Until now, the rule was simple — what comes in, goes out. That made sense when ProxyFeed only processed RSS. But now that it can read Atom, the output should be unified.

The final answer is clear: ProxyFeed will always output valid RSS 2.0 — no matter what format it receives. That change will be part of the next updates.