# Findings — Wiki engine landscape and what it implies for shard-wiki

Date: 2026-06-08 · Status: research draft

Scope: a breadth-first scan of notable wiki engines, read through one question —
**what does this engine's storage and permission model demand of a shard adapter,
and what must shard-wiki therefore NOT assume is uniform?** This is landscape, not
selection: shard-wiki orchestrates over these, it does not pick one.

**Complements:** `research/260608-federation-concepts/` (federation mechanics) and
`research/260608-c2-wiki-origins/` (origin culture). Raw source kept alongside as
`260608-perplexity-wikiengines-research.md`.

---

## 1. The engines, by what they actually are

The "wiki" label spans at least four distinct system shapes. Conflating them is
exactly the mistake shard-wiki's adapter contract exists to prevent.

| Shape | Engines | Storage | Permission model | Page format |
|-------|---------|---------|------------------|-------------|
| **Simple page editor** | C2 (origin), DokuWiki | flat files (DokuWiki: no DB) | open / htaccess / ACL plugin | wiki markup |
| **App platform** | XWiki, TWiki, Foswiki | DB + structured objects | fine-grained, per-space, forms/workflow | macro markup |
| **Internet-scale collaborative** | MediaWiki, Semantic MediaWiki | DB + revision tables | role/group, extension-driven | wikitext (+ semantic annotations) |
| **Personal / single-file** | TiddlyWiki, (Obsidian) | one HTML file / local vault | user-managed, not multi-user | tiddlers / Markdown |
| **Federated / distributed** | Federated Wiki, Fossil, ikiwiki | per-site JSON / repo | per-site sovereignty / VCS auth | JSON story+journal / files |
| **Commercial benchmark** | Confluence | proprietary store | mature enterprise ACL + SSO | proprietary |

The same word, six storage substrates and at least five permission philosophies.

## 2. The two axes that matter for orchestration

Stripping the marketing, engines differ on two axes shard-wiki must model
explicitly rather than flatten:

1. **Storage substrate** — flat files (DokuWiki, Fossil), single file (TiddlyWiki),
   relational DB + revision tables (MediaWiki, XWiki, Confluence), per-site JSON
   journals (Federated Wiki), git repo (Fossil, ikiwiki, Gitea wikis).
2. **Permission philosophy** — open-by-default (C2), file/htaccess gating
   (DokuWiki, yawex), per-space/per-page enterprise ACL (Foswiki, XWiki,
   Confluence), VCS-level auth (Fossil), or *none / user-managed* (TiddlyWiki).

These map directly onto two INTENT concepts:
- Storage substrate → the **shard adapter contract** must not assume one backend.
- Permission philosophy → validates the **L0→L4 access ladder**: real engines
  already span "open C2" to "enterprise ACL + SSO". shard-wiki's ladder is not
  invented; it's the union of where these engines actually sit.

## 3. Capability heterogeneity (why "capability-aware" is non-negotiable)

The scan concretely demonstrates the INTENT principle *capability-aware adapters*:

| Operation | Always available? | Counter-example |
|-----------|-------------------|-----------------|
| Read | ~yes | Confluence behind SSO: not without auth |
| Write | no | C2 today is read-only/archival; MediaWiki dumps are read-only |
| Structured diff/merge | no | DB-backed engines expose revisions but not git-style 3-way merge |
| Semantic query | rarely | only Semantic MediaWiki / XWiki |
| Single-file atomicity | special | TiddlyWiki is whole-file, not per-page, writes |
| Native VCS history | sometimes | Fossil/ikiwiki yes; Confluence no (internal only) |

No adapter can assume a peer supports its own operation set — the capability
profile per shard is load-bearing, not decorative.

## 4. Mapping to shard-wiki INTENT (compare, do not equate)

### 4.1 Reinforcements (engines confirm an INTENT stance)

| Observation | INTENT principle confirmed |
|-------------|----------------------------|
| Six storage substrates under one word | Markdown-first, **backend-neutral**; adapter contract |
| Permission philosophies span open→enterprise | **Open by default, progressively governed** (L0→L4) |
| DB engines expose revisions but not portable history | **Git-addressable coordination** adds the missing portable journal |
| TiddlyWiki/Obsidian = sovereign personal stores | **Local-first usefulness**; shards, not replacements |
| Federated Wiki = union composed from many origins | **Union without erasure** |
| Confluence/Foswiki = mature ACL but lock-in | shard-wiki **delegates** IAM, never owns identity |

### 4.2 Deliberate divergences (design bugs if conflated)

| Engine assumption | shard-wiki correction |
|-------------------|----------------------|
| "Pick the one engine for your team" | shard-wiki attaches *many* as shards; not a single choice |
| App-platform macros define the page | **Markdown-first**; engine-specific render stays out of core |
| Permissions live in the engine's DB | **Authorization in core**, identity delegated — uniform across shards |
| History = the engine's revision table | **Coordination journal** is space-level, git-backed, portable |
| Federation = everyone runs the same engine | Adapter contract spans heterogeneous, non-git, capability-limited backends |

### 4.3 What the landscape teaches that shard-wiki should not lose

1. **Don't homogenize** — the heterogeneity is the user's reality, not a defect to fix.
2. **Openness and governance are a spectrum, not a toggle** — engines live at every
   point C2→Confluence; the ladder must too.
3. **Structured/semantic pages exist** (Semantic MediaWiki, XWiki) — Markdown-first
   must degrade gracefully when a shard carries structure shard-wiki can't model yet.
4. **Single-file/whole-vault write granularity** (TiddlyWiki) breaks per-page write
   assumptions — the capability profile must express write granularity.

## 5. Implications for the adapter contract (carry to SHARD-WP-0002)

1. **Capability profile must encode write granularity** (per-page vs whole-file vs
   whole-space) — TiddlyWiki and DB engines differ here.
2. **History portability is an adapter concern** — engines with internal-only
   revisions (Confluence, MediaWiki) need the coordination journal to supply the
   git-addressable layer they lack.
3. **Structured/semantic payloads need a passthrough/provenance escape hatch** so
   Semantic MediaWiki / XWiki content isn't silently flattened to lossy Markdown.
4. **Permission model is never trusted from the shard** — even engines with rich
   internal ACLs are authorized through shard-wiki's core, not their DB.

## 6. Open questions (for spec / workplans)

1. How does shard-wiki represent **structured/semantic** pages (Semantic MediaWiki,
   XWiki objects) — lossy Markdown projection, sidecar metadata, or opaque blob?
2. **Write granularity** in the capability profile — what's the vocabulary
   (per-page / per-file / per-space / append-only)?
3. For engines with **internal-only history** (Confluence), is the git coordination
   journal authoritative, or a mirror with reconciliation back?
4. Which of these engines get **first-class adapters** vs are reachable only via a
   generic file/WebDAV adapter?

## 7. Sources

| Source | URL |
|--------|-----|
| Perplexity — wiki engines scan (raw, this dir) | `260608-perplexity-wikiengines-research.md` |
| C2 — Top Ten Wiki Engines | http://c2.com/cgi/wiki?TopTenWikiEngines |
| C2 — WikiEngines | https://wiki.c2.com/?WikiEngines |
| Comparison of wiki software | https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software |
| WikiMatrix engine comparison | https://www.wikimatrix.org/ |
| Wiki.js | https://js.wiki |
| Foswiki | https://en.wikipedia.org/wiki/Foswiki |
| Fossil (software) | https://en.wikipedia.org/wiki/Fossil_(software) |
| shard-wiki — federation concepts | `research/260608-federation-concepts/findings.md` |
| shard-wiki — INTENT | `INTENT.md` |

---

## 8. Traceability

| This document section | Informs (future) |
|-----------------------|------------------|
| §2 two axes | Access ladder (INTENT) + adapter contract guardrails |
| §3 capability heterogeneity | Adapter capability profile design |
| §4 INTENT mapping | Architecture blueprint guardrails |
| §5 adapter implications | `workplans/SHARD-WP-0002-federation-architecture.md` |
| §6 open questions | spec — page model for structured/semantic content |