generated from coulomb/repo-seed
tegwick
7d1fb97968
- Add README.md + findings.md to research/260608-wikiengines-overview/ to match sibling research convention (was a bare Perplexity dump). findings.md synthesizes the engine landscape into adapter-contract implications and maps to INTENT (capability heterogeneity, L0->L4 ladder, backend-neutrality). - Mark the netkingdom integration demand as sent: capability request 3136a9e2 (auto-routed to netkingdom) + inbox message 46c60f17. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
8.2 KiB
8.2 KiB
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:
- 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).
- 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
- Don't homogenize — the heterogeneity is the user's reality, not a defect to fix.
- Openness and governance are a spectrum, not a toggle — engines live at every point C2→Confluence; the ladder must too.
- Structured/semantic pages exist (Semantic MediaWiki, XWiki) — Markdown-first must degrade gracefully when a shard carries structure shard-wiki can't model yet.
- 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)
- Capability profile must encode write granularity (per-page vs whole-file vs whole-space) — TiddlyWiki and DB engines differ here.
- 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.
- Structured/semantic payloads need a passthrough/provenance escape hatch so Semantic MediaWiki / XWiki content isn't silently flattened to lossy Markdown.
- 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)
- How does shard-wiki represent structured/semantic pages (Semantic MediaWiki, XWiki objects) — lossy Markdown projection, sidecar metadata, or opaque blob?
- Write granularity in the capability profile — what's the vocabulary (per-page / per-file / per-space / append-only)?
- For engines with internal-only history (Confluence), is the git coordination journal authoritative, or a mirror with reconciliation back?
- 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 |