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.