What is Rho?

In one sentence: Rho is the next evolution of Markdown — it lets .md files express HTML-grade interactivity (sliders, animations, SVG scenes, live charts, knowledge-graph nodes) while keeping Markdown's promise that any tool can open the source as plain text.

Logo: ρ — Greek letter rho, a single glyph that is the logo. Domain: rho.md Product family: Rho (reader app) / @rho/md (npm library) / Rho format (protocol) / cloud.rho.md (SaaS) / Rho AI (generation) / Rho graph (knowledge management)

An example to open with

The way plain markdown does it:

# BMI calculator

Formula: `BMI = weight (kg) / height² (m)`

| Height | 60kg | 70kg | 80kg |
|--------|------|------|------|
| 1.6m   | 23.4 | 27.3 | 31.3 |
| 1.7m   | 20.8 | 24.2 | 27.7 |
| 1.8m   | 18.5 | 21.6 | 24.7 |

The reader has to plug their own numbers into the table.

The way Rho does it:

# BMI calculator

Formula: `BMI = weight (kg) / height² (m)`

```interact
slider weight 40 120 70 1
slider height 1.4 2.1 1.7 0.01
computed bmi = weight / (height * height)
template stl:
[Your BMI] -> [{bmi:.1f}] ::mod(weight="{weight} kg", height="{height} m")
```

The reader drags two sliders → BMI, units, healthy zone all update live — no math required.

The difference is obvious: from "read the formula and compute yourself" to "drag a slider and see the answer."

Key: that ```interact block, in readers that don't support Rho (GitHub / VS Code / default Obsidian), shows as a syntax-highlighted code block — readers can still see what the source does. That's plain-text fallback.

Three core principles

Rho's design rests entirely on these three:

1. Declarative

The source file contains no JS code. Every interaction is a declaration ("put a slider here, min 40, max 120, initial 70"), not code ("function onSliderChange() { ... }").

Why:

• Writers don't need to know how to code
• LLMs can reliably generate it (generating raw JS is bug-prone; generating declarations almost never errors)
• Safe (the reader doesn't eval anything — no user code execution)
• Portable (not tied to any JS framework)

2. Plain-text fallback

Readers that don't support Rho (GitHub web, VS Code preview, default Obsidian, email markdown clients) — when they open a .md file, they see the plain-text source, not a blank failed render.

This is Markdown's core promise; Rho cannot violate it. All Rho DSLs live inside standard markdown fenced code blocks (```interact / ```timeline / ```layout) or :::container blocks — both are legal in standard markdown; they're just rendered as code blocks or ignored.

Important distinction: "openable as plain text" ≠ "visually rendered." Rho guarantees the former. To see actual sliders / animations / live charts, you need Rho MD or another reader that implements the format.

3. AI-friendly (AI-native)

The syntax is compact, unambiguous, machine-verifiable — LLMs produce Rho format almost without errors.

Compare:

• Ask an LLM to write React + useState + Chart.js → frequently broken imports, wrong props, missing useEffect
• Ask it for ```interact \n slider x 0 10 5 0.1 \n template stl: ... ``` → almost always right on first try

The LLM Protocol document (in the Rho AI / LLM Guide section) is specifically for AIs — more compact than the spec.

What it solves

Rho fits these scenarios:

What it doesn't solve

Honest boundaries:

• ❌ Not a web app builder — no full SPA (routing / backend / persistent state)
• ❌ Not a React replacement — you can't write components in markdown
• ❌ Not a Dataview replacement (though Rho graph is heading there) — currently no querying local files / cross-document aggregation
• ❌ Not a PowerPoint replacement — stepper / layout exist, but presentations aren't the focus
• ❌ No form submission / backend — all state lives in the reader's memory; closing the page loses it

If you need any of those, use the right tool. Rho focuses on one thing: let .md files express HTML-grade interactivity that's shareable and portable — while keeping markdown's plain-text fallback.

How it relates to other tools

Objective comparison, not a putdown:

Rho's differentiation isn't "capability unlock" — several of those tools can do similar things. It is:

1. Unified spec (not dozens of incompatible plugins)
2. Declarative (not JS-imperative)
3. AI-friendly (LLMs only need one protocol)
4. Portable (no ecosystem lock-in; source is pure markdown)

Philosophy: why it's designed this way

Markdown beat wiki / RTF / docx / Notion proprietary formats and became the de facto standard for one reason — it has one unbreakable promise:

Any tool can open it; in the worst case you see plain text — not a broken binary or a failed render.

That promise lets .md files flow freely across GitHub / VS Code / Obsidian / Bear / Typora / email clients / the command line / cat / any text editor.

Many "enhanced markdown" formats (MDX / Notion-flavored / Bear-flavored) violate this promise — leave their reader and the file is broken.

Rho refuses that path. Every Rho DSL must, in readers without Rho support, show as legal markdown (fenced code block / container block / regular paragraph). The worst a reader sees is a syntax-highlighted source — not an error.

Cost: the DSL shape is constrained by markdown grammar (must live in ``` or :::). Benefit: your .md files never break because you switched readers.

What's next

See also

• AINP protocol (v0.7) — Full specification, CC BY 4.0
• AINP protocol — §16 For LLM authors — Protocol for AIs generating Rho format
• @rho/md library — Reference implementation on npm (package name pending rename to @rho/md)
• Rho on GitHub — Tauri desktop reader (repo name pending rename)