Dave Winer’s Markdown OPML: A Quiet, Radical Rethink of How We Wire the Web Together

Source: https://source.scripting.com/markdown.opml

In an era where every platform is trying to capture text inside proprietary editors, formats, and AI wrappers, Dave Winer is quietly pushing the opposite vision: content as portable, inspectable, scriptable structure.

The markdown.opml feed at source.scripting.com looks, at first glance, like a curiosity—an outline file with Markdown inside. But for anyone who cares about open tooling, interoperable knowledge, feed formats, and programmable content, it’s much more interesting: a living demonstration of how OPML plus Markdown can act as a universal substrate for the written web.

This is not a new player chasing hype. It’s the same lineage that brought us RSS. Which means: developers should pay attention.

What markdown.opml Actually Is

At its core:

  • It’s an OPML document (Outline Processor Markup Language).
  • Each node is a discrete unit of content—headlines, paragraphs, links, notes.
  • The text within those nodes is Markdown, not bespoke HTML or a closed editor format.

That simple combination has some underappreciated properties:

  1. OPML provides hierarchy and structure: nested outlines, parents/children, relationships between ideas.
  2. Markdown provides readable, lightweight markup: links, emphasis, code, lists—already native to most dev workflows.
  3. The whole thing is trivially parseable: any language, any stack, no binary blobs, no lock-in.

For feed readers, note-taking tools, AI pipelines, knowledge-graph systems, and publishing engines, this is an unusually clean integration point.

Why This Matters to Builders

Most of today’s “content infrastructure” is hostile to composition:

  • Social networks wall off posts behind APIs and rate limits.
  • CMS platforms store rich text in proprietary or framework-specific formats.
  • AI products wrap text in opaque prompts and closed ecosystems.

By contrast, markdown.opml treats structure and content as open primitives:

  • A blog post is an outline.
  • Each section is addressable and transformable.
  • Formatting is Markdown; structure is OPML.
  • The file is a durable URL: tools can subscribe, diff, mirror, or layer semantics on top.

For developers, that unlocks some very practical possibilities.

Concrete Integration Ideas

If you’re building in web, infra, or AI/ML, markdown.opml is less a product and more a protocol sketch. A few high-value use cases:

1. Smarter, Structured Feed Readers

Modern feed readers could:

  • Consume OPML+Markdown to render hierarchical reading views.
  • Allow folding/unfolding sections, mirroring the author’s outline.
  • Subscribe not only to “new posts” but to evolving outlines, watching sections change over time.

Instead of flat, one-shot posts, you get living documents—versionable, navigable, scriptable.

2. Interoperable Knowledge Systems

Note-taking apps, PKM tools, and internal wikis can:

  • Import markdown.opml as native outline structures.
  • Preserve headings, bullets, links, and hierarchy without lossy HTML scraping.
  • Sync selectively: subscribe to a subset of nodes (e.g., a specific outline branch).

That’s a direct counter-design to siloed, proprietary knowledge graphs. The “API” is just open text.

3. Clean Input for AI and RAG Pipelines

For teams building retrieval-augmented generation systems, this format is gold:

  • OPML hierarchy gives you natural document chunking.
  • Markdown markup gives hints about code, emphasis, and links.
  • You can map each outline node to an embedding unit, preserving context via its parent/child relationships.

Instead of scraping HTML and heuristically guessing structure, you start with an explicit semantic backbone.

A minimal conceptual flow:

fetch markdown.opml
parse OPML -> nodes[]
for node in nodes:
    text = renderMarkdown(node.text)
    parent_context = collectAncestors(node)
    embedding = embed(parent_context + "
" + text)
    index(embedding, metadata={id, depth, path})

That simplicity compounds in production systems.

4. Programmable Publishing Pipelines

Publishers and developer-doc teams can treat OPML+Markdown as the single source of truth:

  • Author in an outliner that exports to markdown.opml.
  • Transform it into:
    • Static sites
    • PDF/EPUB
    • API docs
    • In-app help overlays

No complex CMS dependencies required. The operational story becomes:

  • Git for versioning.
  • OPML for structure.
  • Markdown for content.
  • A small set of build scripts for output targets.

Technical Characteristics Worth Noticing

A few details that make this pattern robust:

  • Deterministic parsing: Both OPML (XML) and Markdown are widely supported, with mature libraries.
  • Tooling-agnostic: Any editor that can write Markdown can feed this; any system that can parse XML can consume it.
  • Extensible attributes: OPML nodes can carry custom attributes (type, created, url, etc.), allowing domain-specific semantics without breaking compatibility.
  • Stream-friendly: Because OPML is hierarchical and linearly serializable, it’s easy to diff, sync, and stream.

Nothing here depends on a single vendor. That’s the point.

How This Fits into the Larger Web Story

What Winer is doing with markdown.opml is consistent with a decades-long thesis:

  • Content should be open, linkable, subscribable.
  • Formats should be simple enough to hand-inspect and script.
  • Infrastructure should encourage ecosystems, not walled gardens.

In the current cycle—where AI vendors increasingly want to own both your editor and your corpus—this kind of open, structural format is more than nostalgia. It’s strategy.

For teams building developer tools, AI agents, doc platforms, or reader experiences, adopting an OPML+Markdown-style model (or at least supporting it) offers:

  • Lower integration friction.
  • Higher content portability for your users.
  • A cleaner substrate for semantic search and automation.

Where Developers Can Push This Next

If you’re curious—or skeptical—the next steps are concrete and low-friction:

  • Build a minimal client that subscribes to https://source.scripting.com/markdown.opml and renders it as a live outline.
  • Add support in your PKM or documentation tool for importing/exporting OPML+Markdown.
  • Experiment with treating outlines as first-class citizens in your AI pipelines: hierarchy as context, not noise.

The bigger question isn’t whether this single feed becomes widely adopted. It’s whether we, as an industry, still have the appetite to design around open, composable formats when it’s so tempting to centralize.

markdown.opml is a small file with an unfashionably big opinion: the web works better when its writing is both human-readable and machine-native. The rest is up to the builders.