guides

Draft

How does /merge help me discover new content?

ยท by Eric Moore ยท 3 min read

When we built /merge, we described it as a migration tool: paste two OPML files, get their union, intersection, or difference. The framing was mostly practical โ€” the question it answered was "I'm moving from NewsBlur to feed.works, help me combine my old export with my new one." Real use case, still works.

But the tool has grown a second life that we didn't fully call out at launch: it's a discovery engine.

Feed readers are notoriously bad at discovery. Algorithms do discovery well at the cost of everything else we care about; marketplace-style "here's what's popular" tabs feel generic; social-graph recommendations depend on having a social graph that knows you read feeds. The blank- slate problem โ€” "I just set up my reader; what do I follow?" โ€” is still unsolved for most people.

The three set operations in /merge each answer a different version of that problem, and they don't need an algorithm to do it.

With a friend

Paste your OPML on the left. Paste your friend's OPML on the right. Hit intersection. What comes back is the list of feeds you both already read โ€” the overlap of your taste.

This sounds boring until you try it and realize you had no idea what the overlap was. You'll find feeds your friend follows that you didn't know they cared about. Feeds you follow that you didn't realize they also read. The intersection is a cheap, honest signal about where your reading taste actually aligns โ€” cheaper than a conversation, more accurate than a recommendation.

Then run it again as difference. Your OPML minus theirs: what you read that they don't. Their OPML minus yours: what they read that you don't. Those two lists are the most personal recommendations you'll ever get. No model. No ranking. Just "here's what your friend reads that you're not reading yet."

Diff against a curated list

Half the web publishes "here are the feeds I follow" posts. A researcher in your field shares their OPML. A newsletter maintains a public "starter pack." A blogging ring publishes a community export.

Paste yours on the left. Paste the curated list on the right. Hit difference in the direction R โˆ’ L โ€” "what's in the curated list that I'm not already subscribed to?" That's your discovery list. Import it, skim the next week, unsubscribe from what doesn't earn the space.

The curated-list-as-OPML pattern is underused on the modern web, mostly because people don't know they can publish one. Every reader exports OPML. Every writer who follows a few hundred things has an opinionated list sitting on disk. Publishing that list is a one-command operation. If you write a post that touches a topic you care about, consider ending it with your OPML for readers who want to go deeper.

Aggregate many lists

Run union across three or four curated lists to see what they all recommend. Run intersection to find the feeds that show up in every list โ€” the consensus picks in a specialty. Run difference to find the fringe: what one list includes that none of the others do.

You've just done topic-level discovery without an algorithm. The feeds did the work. You're reading the signal.

Why this works

Discovery-by-aggregation has a property that algorithmic discovery doesn't: the unit being recommended is a feed, not a post. A feed is a relationship with a writer or a source over time. When you accept a recommendation, you're committing to a long-running relationship, not a one-time read. That filters the signal heavily. An algorithm can surface a hundred posts you'd vaguely enjoy; a friend's OPML surfaces a dozen writers whose next ten posts you'll probably want to read.

/merge is free, runs in your browser, and doesn't require an account. You can point it at any two OPML files, including your own at different points in time (diff last year's export against this year's to see how your taste drifted). Paste, click, skim. Everything you need for discovery, without algorithmic mediation.