coulomb/shard-wiki
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

research: write up wiki-engines landscape scan; send IAM demand to netkingdom

Browse Source 
- 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>
This commit is contained in:
Bernd Worsch
2026-06-13 18:18:45 +02:00
parent 81cfce10d2
commit 7d1fb97968
4 changed files with 580 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
demand/260608-netkingdom-integration-requirements.md
View File

@@ -82,8 +82,10 @@ shard-wiki authorizes; it never authenticates or stores identity. Everything bel
## Next actions
- [ ] Send this as a **capability request / interface negotiation** to the netkingdom domain
(user-engine + net-kingdom owners) via the state hub.
- [x] Send this as a **capability request / interface negotiation** to the netkingdom domain
(user-engine + net-kingdom owners) via the state hub. — *sent 2026-06-13, capability
request `3136a9e2-0c1a-4b3f-8a02-ef47b27071fe` (auto-routed to `netkingdom`), inbox
message `46c60f17`.*
- [ ] Lock the **token claim contract** (A2–A4) and the **membership read API** (B1–B5) first
— they gate everything L2+.
- [ ] Define shard-wiki's **audit event schema** (C1) against user-engine's existing audit model.

397
research/260608-wikiengines-overview/260608-perplexity-wikiengines-research.md Normal file
View File

@@ -0,0 +1,397 @@
# Perplexity Research Wiki Engines
Source: https://www.perplexity.ai/search/9b76560e-31b7-4465-87a4-01a9df9cdbbe#1
## What are the most technically interesting wiki engines out there?
Below is an expanded, more technical map of the wiki landscape, including your additions: C2, Federated Wiki, TWiki, Confluence, Semantic MediaWiki, TiddlyWiki, Fossil, and the Tcl-based option I found. I’ve kept the focus on what each system is *for*, what makes it distinct, and what kind of adoption it seems to have had. [c2](http://c2.com/cgi/wiki?TopTenWikiEngines)
## Wiki.js
Wiki.js is a modern, extensible, self-hosted wiki aimed at polished documentation and flexible deployment. It feels like the “modern web app” interpretation of a wiki. [js](https://js.wiki)
**USPs**
- Modern UI and authoring experience.
- Extensible architecture.
- Self-hosted and open source. [wikimatrix](https://www.wikimatrix.org/compare/wiki-js+dokuwiki+xwiki+mediawiki+tiki-wiki-cms-groupware+tiddlywiki)
**Strengths**
- Strong for documentation teams that want low-friction editing.
- Good fit when you want a contemporary stack and a clean UX.
- Broadly positioned as “powerful and extensible.” [js](https://js.wiki)
**Weaknesses**
- Less historically proven than MediaWiki or TWiki in huge legacy enterprise environments.
- Smaller ecosystem than the oldest wiki engines.
- Not as “structured application platform” oriented as Foswiki/XWiki. [wikimatrix](https://www.wikimatrix.org/compare/wiki-js+dokuwiki+xwiki+mediawiki+tiki-wiki-cms-groupware+tiddlywiki)
**Characteristic use cases**
- Internal docs.
- Product documentation.
- Team knowledge bases.
- Self-hosted alternative to SaaS doc tools. [js](https://js.wiki)
**Userbase estimate**
- Likely **tens of thousands of active deployments/users**, but public numbers are not well standardized. That makes it a strong product choice, but not a giant legacy ecosystem like MediaWiki or TWiki. [wikimatrix](https://www.wikimatrix.org/compare/wiki-js+dokuwiki+xwiki+mediawiki+tiki-wiki-cms-groupware+tiddlywiki)
## XWiki
XWiki is a programmable wiki platform that blurs the line between wiki and lightweight application platform. It is technically interesting because it supports scripts, macros, and application-style pages. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**USPs**
- Scriptable pages and apps.
- Strong extension model.
- Syntax compatibility with other wiki styles. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Strengths**
- Great for building structured internal tools.
- More “platform-like” than plain wiki software.
- Good fit for teams that need dynamic content and forms. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Weaknesses**
- More complexity than simpler wikis.
- Can feel heavyweight if you only want plain documentation.
- Requires more governance and administration. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Characteristic use cases**
- Enterprise knowledge bases.
- Internal business applications.
- Structured reporting and collaborative workflows.
- Documentation that needs embedded logic. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Userbase estimate**
- Probably **tens of thousands to low hundreds of thousands** of users across deployments, but public install counts are not clearly disclosed. [wikimatrix](https://www.wikimatrix.org/compare/wiki-js+dokuwiki+xwiki+mediawiki+tiki-wiki-cms-groupware+tiddlywiki)
## MediaWiki
MediaWiki is the canonical large-scale wiki engine: boring in the best possible way, because it works at enormous scale and has an enormous extension ecosystem. It remains technically important because it set the pattern for high-volume collaborative editing. [herothemes](https://herothemes.com/blog/wiki-software/)
**USPs**
- Proven at internet scale.
- Huge extension ecosystem.
- Strong revision/history and collaboration model. [herothemes](https://herothemes.com/blog/wiki-software/)
**Strengths**
- Best-in-class for public, high-traffic, multi-author wikis.
- Extremely mature.
- Broad tooling and community support. [herothemes](https://herothemes.com/blog/wiki-software/)
**Weaknesses**
- Can be operationally heavy.
- Editing experience is not the smoothest by default.
- Often overkill for small internal knowledge bases. [herothemes](https://herothemes.com/blog/wiki-software/)
**Characteristic use cases**
- Wikipedia-style public encyclopedias.
- Community knowledge bases.
- Large multilingual collaborative sites.
- Semantic layering via extensions. [herothemes](https://herothemes.com/blog/wiki-software/)
**Userbase estimate**
- By far the largest in this group; think **millions of contributors and readers across many thousands of sites**. [c2](http://c2.com/cgi/wiki?TopTenWikiEngines)
## Semantic MediaWiki
Semantic MediaWiki is technically interesting because it turns wiki pages into queryable knowledge objects. It is less “just a wiki” and more a semantic knowledge base on top of MediaWiki. [en.wikipedia](https://en.wikipedia.org/wiki/Foswiki)
**USPs**
- Semantic annotations.
- Queryable structured content.
- Strong fit for knowledge management with ontology-like behavior. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Strengths**
- Very powerful for structured knowledge capture.
- Supports reporting and retrieval beyond full-text search.
- Bridges freeform wiki editing and data-driven retrieval. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Weaknesses**
- Steeper learning curve.
- Requires discipline in content modeling.
- More complex than plain wiki editing. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Characteristic use cases**
- Research knowledge bases.
- Reference systems with structured facts.
- Enterprise knowledge graphs and catalogs.
- Areas where pages should behave like data records. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Userbase estimate**
- Smaller than MediaWiki, but meaningful in specialist knowledge-management circles: likely **thousands of sites, not millions**. [en.wikipedia](https://en.wikipedia.org/wiki/Foswiki)
## DokuWiki
DokuWiki is the classic lightweight, file-based wiki: simple, pragmatic, and still technically elegant because it avoids a database. It is a workhorse for teams that want low operational overhead. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
**USPs**
- No database required.
- Simple deployment.
- Large plugin ecosystem. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
**Strengths**
- Easy to run and back up.
- Good text/wiki syntax experience.
- Reliable for small-to-medium teams. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
**Weaknesses**
- Less suited to highly structured app-like workflows.
- Not the strongest choice for huge public communities.
- Interface feels older than modern doc platforms. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
**Characteristic use cases**
- Internal docs.
- Departmental knowledge bases.
- Small team collaboration.
- Simple intranets and technical notes. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
**Userbase estimate**
- Likely **tens of thousands of installations**; broad but not dominant. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
## TiddlyWiki
TiddlyWiki is one of the most technically unusual wiki engines because it is often a single self-contained HTML file that acts like a personal knowledge system. That makes it deeply portable and hackable. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**USPs**
- Single-file architecture.
- Highly personal and portable.
- Strong customization via plugins/macros/themes. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Strengths**
- Great for personal knowledge management.
- Easy to carry around and version-control.
- Extremely flexible for power users. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Weaknesses**
- Not a conventional multi-user server wiki.
- Collaboration and permissions are not its core strength.
- Can become messy without personal discipline. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Characteristic use cases**
- Personal notes.
- Research notebooks.
- Offline-first knowledge bases.
- Individual knowledge workflows. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Userbase estimate**
- Probably **tens of thousands to a few hundred thousand users**, with a strong enthusiast niche. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
## TWiki
TWiki is a structured enterprise wiki that emerged from enterprise demand rather than minimalist wiki ideals. It is interesting because it became a platform for forms, workflows, and application-like pages. [junauza](https://www.junauza.com/2008/05/five-of-best-freeopen-source-wiki.html)
**USPs**
- Enterprise collaboration platform.
- Strong extensibility, with hundreds of extensions.
- Structured content and application building. [sourceforge](https://sourceforge.net/projects/twiki/)
**Strengths**
- Proven in corporate environments.
- Great for structured team workflows.
- Strong fit for intranets and process-heavy use. [sourceforge](https://sourceforge.net/projects/twiki/)
**Weaknesses**
- Older design philosophy.
- Can feel complex and procedural.
- Less attractive for lightweight modern docs. [sourceforge](https://sourceforge.net/projects/twiki/)
**Characteristic use cases**
- Corporate intranets.
- Team collaboration.
- Project tracking.
- Enterprise knowledge management. [junauza](https://www.junauza.com/2008/05/five-of-best-freeopen-source-wiki.html)
**Userbase estimate**
- SourceForge’s description claims **50,000 small businesses, many Fortune 500 companies, and millions of people** use TWiki, though that should be treated as a vendor-style estimate rather than audited usage data. [sourceforge](https://sourceforge.net/projects/twiki/)
## Foswiki
Foswiki is the continuation of the structured enterprise-wiki tradition, with strong emphasis on collaboration, plugins, and business use. It is technically interesting because it treats the wiki as an application platform with macros, forms, and reporting. [sourceforge](https://sourceforge.net/projects/foswiki/)
**USPs**
- Enterprise wiki and collaboration platform.
- Application-building via markup and macros.
- Fine-grained access control and auditability. [sourceforge](https://sourceforge.net/projects/foswiki/)
**Strengths**
- Strong fit for controlled enterprise environments.
- Very flexible for internal business applications.
- Deep extension model and workflow-style usage. [en.wikipedia](https://en.wikipedia.org/wiki/Foswiki)
**Weaknesses**
- Heavier and more specialized than lightweight wikis.
- UX is functional rather than modern-first.
- Best when governance and structure matter more than simplicity. [sourceforge](https://sourceforge.net/projects/foswiki/)
**Characteristic use cases**
- Knowledge bases.
- Team collaboration portals.
- Workflow and project tracking.
- Document management and structured reporting. [hpcsupport.utsa](http://hpcsupport.utsa.edu/foswiki/bin/view/System/WikiCulture)
**Userbase estimate**
- Likely **thousands to tens of thousands of active users/deployments**, with a strong enterprise niche rather than mass-market scale. [en.wikipedia](https://en.wikipedia.org/wiki/Foswiki)
## Confluence
Confluence is the enterprise commercial benchmark for team wikis, but technically it is more a knowledge collaboration platform than a pure wiki engine. It matters because many organizations chose it as the default workplace knowledge layer. [herothemes](https://herothemes.com/blog/wiki-software/)
**USPs**
- Tight enterprise integration.
- Mature permissions and collaboration.
- Large marketplace ecosystem. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Strengths**
- Strong adoption in enterprises.
- Good for cross-team documentation and workflows.
- Familiar to many business users. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Weaknesses**
- Commercial lock-in.
- Less transparent/inspectable than open-source engines.
- Can become sprawling and hard to govern at scale. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Characteristic use cases**
- Enterprise documentation.
- Project spaces.
- Meeting notes and cross-functional knowledge sharing.
- Regulated orgs that need access control and audit trails. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Userbase estimate**
- Very large enterprise footprint, plausibly **millions of users** across customers, but exact counts are not public. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
## C2
C2 is historically important because it sits close to the origin story of wiki culture and especially “wiki engine as a social process,” not merely software. It is less a mainstream product choice today and more a foundational technical-cultural reference point. [wiki.c2](https://wiki.c2.com/?WikiEngines)
**USPs**
- Foundational wiki culture.
- Minimalist and historically influential.
- Strong association with Ward Cunningham’s original ideas. [wiki.c2](https://wiki.c2.com/?WikiEngines)
**Strengths**
- Very important conceptually.
- Captures the original wiki ethos.
- Useful as a reference model for design thinking. [c2](http://c2.com/cgi/wiki?TopTenWikiEngines)
**Weaknesses**
- Not a modern enterprise product.
- Limited contemporary ecosystem.
- Not typically chosen for new production deployments. [wiki.c2](https://wiki.c2.com/?WikiEngines)
**Characteristic use cases**
- Early collaborative documentation.
- Idea exploration.
- Community knowledge sharing.
- Historical origin of wiki practice. [c2](http://c2.com/cgi/wiki?TopTenWikiEngines)
**Userbase estimate**
- Modern active userbase is likely **very small**, mostly historical and enthusiast usage. [wiki.c2](https://wiki.c2.com/?WikiEngines)
## Federated Wiki
Federated Wiki is one of the most intellectually interesting designs because Ward Cunningham pushed the idea beyond a central shared wiki toward a network of interoperating personal sites. It is a reaction against the assumptions of centralized knowledge ownership. [wiki.c2](https://wiki.c2.com/?WikiEngines)
**USPs**
- Federated, distributed model.
- Personal control with sharing across sites.
- Strong conceptual innovation. [wiki.c2](https://wiki.c2.com/?WikiEngines)
**Strengths**
- Excellent for decentralization-minded users.
- Encourages personal ownership of notes and pages.
- Very distinctive architecture. [wiki.c2](https://wiki.c2.com/?WikiEngines)
**Weaknesses**
- Smaller ecosystem.
- Less mainstream operational tooling.
- Can be harder for teams expecting centralized permissions and governance. [wiki.c2](https://wiki.c2.com/?WikiEngines)
**Characteristic use cases**
- Personal knowledge networks.
- Distributed collaboration.
- Experimental knowledge sharing.
- Communities interested in networked authorship. [wiki.c2](https://wiki.c2.com/?WikiEngines)
**Userbase estimate**
- Probably **small niche adoption**, more influential than widely deployed. [wiki.c2](https://wiki.c2.com/?WikiEngines)
## TiddlyWiki
TiddlyWiki is already covered above as one of the core additions, but it deserves emphasis: it is the most “personal-computing” oriented wiki in this list. Its architecture is a big reason it remains technically admired. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**USPs**
- Portable single-file personal wiki.
- Deep customization.
- Offline-friendly. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Strengths**
- Great for individual workflows.
- Easy to archive and transport.
- Powerful for note structuring and metadata. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Weaknesses**
- Not a natural fit for large teams.
- Sync/conflict handling is user-managed.
- Can be too freeform for rigid organizations. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Characteristic use cases**
- Zettelkasten-like note systems.
- Research and personal PKM.
- Portable offline notes.
- Solo technical planning. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
**Userbase estimate**
- Niche but durable: **tens of thousands to low hundreds of thousands**. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
## Fossil
Fossil is technically interesting because it bundles version control, bug tracking, and wiki/documentation into one system. Its wiki is part of a developer workflow, not a standalone knowledge product. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
**USPs**
- Integrated VCS, issue tracker, and wiki.
- Single-tool developer workflow.
- Simple, self-contained project hosting. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
**Strengths**
- Excellent for small to medium software projects.
- Tight coupling between code, tickets, and docs.
- Strong for maintaining project history. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
**Weaknesses**
- Not a general-purpose wiki platform.
- Smaller ecosystem than GitHub/GitLab-style stacks.
- More dev-centric than business-user-centric. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
**Characteristic use cases**
- Software project documentation.
- Developer-run issue tracking and wiki pages.
- Integrated team repositories.
- Small tooling-centric open-source projects. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
**Userbase estimate**
- Likely **tens of thousands of users**, mostly among developers and small project teams. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
## Tcl wiki option
The Tcl ecosystem does have a wiki presence, but the result I found is mainly **Tcler's Wiki**, which is a wiki for the Tcl community rather than clear evidence of a widely used Tcl-native standalone engine. So I would not confidently label it as a major separate engine without more evidence. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
**USPs**
- Community knowledge base for Tcl.
- Demonstrates Tcl community use of wiki patterns. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
**Strengths**
- Niche relevance for Tcl users.
- Good example of a community-maintained knowledge base. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
**Weaknesses**
- Not clearly a mainstream, distinct wiki engine product.
- Limited evidence of broad adoption beyond the Tcl community. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
**Characteristic use cases**
- Tcl community documentation.
- Shared project knowledge.
- Language-specific community support. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
**Userbase estimate**
- Very small, niche community usage. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
## What stands out most
If you want the most technically distinctive group, I’d rank them this way: **Federated Wiki** for distributed architecture, **TiddlyWiki** for single-file personal knowledge, **Semantic MediaWiki** for queryable structure, **Fossil** for integrated dev workflow, and **Foswiki/TWiki** for enterprise wiki-as-application platforms. [en.wikipedia](https://en.wikipedia.org/wiki/Foswiki)
The older engines are still interesting because they reflect different answers to the same design question: should a wiki be a simple page editor, a structured app platform, or a knowledge graph with a browser front end? [c2](http://c2.com/cgi/wiki?TopTenWikiEngines)
# Possible Follow Ups
- How do the underlying data architectures of these wiki engines impact long-term knowledge curation and data longeevity?
- How does TiddlyWiki manage non-linear storage in a single file?
- How do Semantic MediaWiki graph capabilities compare to modern graph DBs?
- What architectural challenges led to the creation of Federated Wiki?
- How does Fossil provide version control and wiki in one binary?

32
research/260608-wikiengines-overview/README.md Normal file
View File

@@ -0,0 +1,32 @@
# 260608 — Wiki engines overview (landscape scan)
Date: 2026-06-08
## What this is
A breadth-first **landscape scan of notable wiki engines** — Wiki.js, XWiki,
MediaWiki, Semantic MediaWiki, DokuWiki, TiddlyWiki, TWiki, Foswiki, Confluence,
C2, Federated Wiki, Fossil — captured to understand the design space
`shard-wiki` orchestrates over (and deliberately does **not** re-implement).
Complements the deeper-dive research:
- `research/260608-c2-wiki-origins/` — pre-federation wiki culture
- `research/260608-federation-concepts/` — Federated Wiki, git/AP federation models
- `research/260608-yawex-prior-art/` — the specific Perl engine being superseded
Focus: what each engine is *for*, its storage/permission model, and what its
existence implies for shard-wiki's **adapter contract** — not engine selection.
## Contents
| Path | Role |
|------|------|
| `findings.md` | Synthesis: storage/permission axes, shard-wiki mapping, adapter implications, open questions |
| `260608-perplexity-wikiengines-research.md` | Raw source dump (Perplexity), kept as provenance |
## Status
Initial scan complete. Reinforces the INTENT stance that shard-wiki is an
**orchestrator, not an engine**: the heterogeneity below is the problem space,
not a menu to pick from. Adapter-contract implications feed
`workplans/SHARD-WP-0002-federation-architecture.md`.

147
research/260608-wikiengines-overview/findings.md Normal file
View File

@@ -0,0 +1,147 @@
# 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 |