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>
148 lines
8.2 KiB
Markdown
148 lines
8.2 KiB
Markdown
# 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 |
|