From 7d1fb979688cbb5bbfc24636530b155af086da1d Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 13 Jun 2026 18:18:45 +0200 Subject: [PATCH] research: write up wiki-engines landscape scan; send IAM demand to netkingdom - 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 --- ...608-netkingdom-integration-requirements.md | 6 +- .../260608-perplexity-wikiengines-research.md | 397 ++++++++++++++++++ .../260608-wikiengines-overview/README.md | 32 ++ .../260608-wikiengines-overview/findings.md | 147 +++++++ 4 files changed, 580 insertions(+), 2 deletions(-) create mode 100644 research/260608-wikiengines-overview/260608-perplexity-wikiengines-research.md create mode 100644 research/260608-wikiengines-overview/README.md create mode 100644 research/260608-wikiengines-overview/findings.md diff --git a/demand/260608-netkingdom-integration-requirements.md b/demand/260608-netkingdom-integration-requirements.md index 08f7f59..4e7899c 100644 --- a/demand/260608-netkingdom-integration-requirements.md +++ b/demand/260608-netkingdom-integration-requirements.md @@ -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. diff --git a/research/260608-wikiengines-overview/260608-perplexity-wikiengines-research.md b/research/260608-wikiengines-overview/260608-perplexity-wikiengines-research.md new file mode 100644 index 0000000..ea90dc8 --- /dev/null +++ b/research/260608-wikiengines-overview/260608-perplexity-wikiengines-research.md @@ -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? + + + diff --git a/research/260608-wikiengines-overview/README.md b/research/260608-wikiengines-overview/README.md new file mode 100644 index 0000000..5c0b4a1 --- /dev/null +++ b/research/260608-wikiengines-overview/README.md @@ -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`. diff --git a/research/260608-wikiengines-overview/findings.md b/research/260608-wikiengines-overview/findings.md new file mode 100644 index 0000000..b223988 --- /dev/null +++ b/research/260608-wikiengines-overview/findings.md @@ -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 |