A Feature Request: Support for Static .md Outputs & Discovery

Motivation: A Simpler, Less Exploitative Web

I’ve been interested in a simpler, less exploitative web for a long time. It feels like the modern web is increasingly dominated by ads, intrusive surveillance, tracking scripts, and bloated layouts that mock our control over our own reading decisions.

I’ve explored simpler alternative networks like Gopher and the Gemini protocol to find a quieter reading experience. But separate protocols don’t fit smoothly into my existing publishing workflow. They require running parallel infrastructure, managing new server software, and creating extra publishing overhead.

At the same time, recent developments in AI have rapidly turned Markdown into the default lingua franca of the web. Micro.blog users already author their posts in native Markdown, as does everyone using a static site, so converting that source into HTML only to have tools and readers parse it back into text feels a bit redundant. Why not cut out the middleman and directly serve the original Markdown to anyone, human or software agent, who chooses to read it?

The Web of Markdown ‘movement’ (maybe that’s a bit premature) feels like a practical way forward. It allows us to achieve calm, distraction-free, text-first reading directly on the HTTP(S) web we already use, without abandoning open standards or adding friction to our existing publishing stack. TBH, I don’t really understand why this isn’t already possible. Maybe it’s because people really love their wonderful graphics and styling and JavaScript functionality and html served programmatically etc. etc. I do too, but not for everything. Some sites are just simple. For many, simple is boring and obsolete, and won’t achieve what’s required. But can’t we at least have an option to stay simple? The recent AI love affair with Markdown may be a moment of opportunity to correct this.

Summary

I would like to propose support for the Web of Markdown philosophy across Micro.blog sites—either as an official community plugin or ultimately as a native platform toggle under Design Settings.

As discussed across the web (e.g., Dave Winer’s Scripting News, Andrew Shell and his https://md.geekity.com, and scanners like IsItAgentReady), serving lightweight, unstyled Markdown alongside HTML makes sites instantly readable for distraction-free clients, RSS/Markdown aggregators, and AI agents. Because Micro.blog stores post content in Markdown natively and uses Hugo as its rendering engine, it’s well-positioned to move forward on this emerging standard.

I’m not suggesting this proposal would solve all problems, or even many problems. As a counterpoint, I should perhaps mention Joost de Valk’s EmDash CMS. EmDash takes an agent-native, JSON-structured approach under the hood rather than relying solely on flat text files, though it still supports Markdown for round-trip editing. But that addresses a slightly different use-case: managing a CMS backend. Whereas I see serving clean Markdown as handy because both humans and bots can read the published output without much difficulty.

Apologies in advance for using AI to come up with a draft project scope, since I’m keen but have no idea what I’m doing. Please let me know what you think (about the concept, that is, not my incompetence).

Technical Specifications & Compatibility Requirements (Click to expand)

1. Static Markdown File Generation

Every published post and standalone page should build an accompanying Markdown endpoint at a predictable path (e.g., /post-slug/index.md or /post-slug.md).

  • Content: The generated file outputs the .RawContent of the post with Hugo shortcodes evaluated or cleaned.

  • Headers & Metadata: Plain-text header metadata at the top linking to the canonical source:

    # Post Title
Date: YYYY-MM-DD
Canonical URL: https://example.com/post-slug/

[Original Markdown body content]

  • MIME Type: Static file delivery or edge routing must return Content-Type: text/markdown; charset=utf-8.

Inject a discovery tag into the HTML <head> on single posts and pages:

<link rel="alternate" type="text/markdown" href="https://example.com/post-slug/index.md" title="Markdown version">

3. SEO & Canonicalization

  • The primary HTML page remains the primary canonical URL (<link rel="canonical" href="...">).

  • The .md file explicitly references the HTML permalink as its canonical URL.

  • Server responses for Content Negotiation include Vary: Accept headers to keep CDN/edge caches clear.

4. Root Level llms.txt (Optional Extension)

Generate /llms.txt at the root, listing recent posts pointing directly to their .md endpoints for streamlined indexing.

Implementation Scope & Roadmap

  • Option A: Proof-of-Concept Plugin

    A packaged Micro.blog plugin supplying custom Hugo output definitions (config.json), a custom rendering layout (layouts/_default/single.md), and a <head> partial injection (layouts/partials/head.html).

  • Option B: Native Platform Integration

    A built-in toggle in Design Settings (“Enable Markdown endpoints for posts”). Bonus: Server/edge support for HTTP Content Negotiation (responding with Markdown directly when a request carries an Accept: text/markdown header).

Some benefits for Micro.blog

  • Distraction-Free Reading: Provides clean text endpoints without JavaScript or styling overhead.

  • Agent & Reader Readiness: Complies with emerging web standards (isitagentready.com / md.geekity.com).

  • Low Overhead: Leverages existing Hugo output formats with minimal impact on build times.