Network/Register/Wikitext Interop And Mdx Canonical Format
Gap Register
G-070Public

Wikitext interop & MDX-canonical format (forking & editor on-ramp)

Tier 2 — Structurally thin, not launch-blocking
Status
Open — design drafted
Owner
Creator
Why now
MediaWiki admins/editors are the talent OLN wants to attract, and they love MediaWiki. Offering wikitext import/export lowers their switching cost and makes forking simple (a direct answer to Fandom's portability grievance) — without adopting wikitext as the canonical paradigm. MDX-over-Facts stays canonical (Entry 029); wikitext is edge interchange. Needs a design.
Depends on
G-057
Related
Entry 029, Entry 003, Entry 009, G-019, G-030, G-057, G-062, G-026, G-060

Backwards-compatibility layer: import and export MediaWiki wikitext while the canonical store is MDX-over-Facts. Three representations — wikitext (interchange) ⇄ MDX (canonical prose + components) over the Fact graph. Wikitext is an on-ramp and a portability guarantee, not the canonical model.

Why this matters

To win editors/admins from MediaWiki platforms, reduce switching cost: let them fork in (import their wikitext/MediaWiki dump) and fork out (export wikitext) — killing lock-in, a direct answer to the Fandom portability/hostile-fork grievance (Entry 003, G-019). Done right, import feeds the Fact graph rather than fighting it.

Directional intent

  • MDX is canonical (Markdown + JSX components): portable like wikitext, but can embed Fact-bound, adaptive, and spoiler-gated components (Entry 029), and it's Next-native (the app already renders markdown).
  • Wikitext is edge interchange — import + export only.
  • Backwards-compat is an on-ramp + portability guarantee, NOT the canonical paradigm. Guardrail against quietly becoming MediaWiki again and losing the prose→Facts thesis (Entry 029).

Three representations

wikitext ⇄ MDX (canonical prose + components) —is a view over→ Fact graph

What maps where (import)

Wikitext elementMaps toNote
Infoboxes / structured templatesFacts / entity attributesthe most structured part of a wiki — best first ingestion target (proto-Facts)
[[wikilinks]]entity referencesthe G-062 prose↔Fact linking primitive, free on import
<ref> citationsper-Fact provenanceG-026 + citation tiers (Entry 020)
Body proseMDX proseprogressively enriched into Facts (G-057)
Categoriestags / graph edges

Hard walls (round-trips are lossy)

  • Templates + Lua/Scribunto modules are a mini-programming-language. Map the common ones (infobox, cite) to components/Facts; flag the rest for human conversion via the review queue (G-060) — do not try to execute MediaWiki wholesale.
  • Export flattens Fact-bound components back to static wikitext (lossy the other way; acceptable for a portability guarantee).
  • Wikitext→MDX→wikitext is not byte-lossless; set expectations accordingly.

Open decisions

  • Round-trip fidelity scope: what is preserved / transformed / dropped.
  • Template & Lua handling: which templates get first-class component/Fact mappings; how unsupported templates are surfaced for human conversion.
  • Export guarantees: how faithful, how often, and what a "portable export" includes (prose + Facts + attribution/history).
  • How much wikitext-syntax editing to support as an on-ramp vs. steering editors to structured authoring (G-057) — and how to keep wikitext from becoming the de-facto paradigm.
  • Relationship to the migration pipeline (G-030): MediaWiki XML dump → wikitext → MDX + Facts.

Related

  • Entry 029 — prose→Facts thesis (the paradigm wikitext must not displace)
  • Entry 003 — forking as first-class · G-019 — data portability (export = anti-lock-in)
  • Entry 009 / G-030 — migration pipeline (dump → wikitext → MDX + Facts)
  • G-057 — prose-to-Fact authoring · G-062 — prose↔Fact linking (wikilinks feed it)
  • G-026 — Fact provenance (refs feed it) · G-060 — review queue (unsupported-template conversion)