# Findings — Federation concepts for decentralized, unified information spaces

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

Scope: federation models that let independently stored knowledge participate in
a **joined view** without erasing provenance, sovereignty, or backend
differences. Primary anchor: **Federated Wiki** and Ward Cunningham's
post-c2 inversion. Secondary: git-backed wikis, ActivityPub wiki extensions,
Xanadu hypertext patterns, and yawex multi-wiki resolution.

**Complements:** `research/260608-c2-wiki-origins/` (federation explicitly
deferred there) and `research/260608-yawex-prior-art/` (REMOTE/VIRTUAL as
adapter foreshadowing).

---

## 1. Why federation (the problem statement)

Centralized wikis concentrate **meaning** and **records** on one server:

| Problem | Manifestation |
|---------|---------------|
| **Ownership** | Contributors build on someone else's host; site shutdown = loss risk |
| **Consensus pressure** | Early edits must survive notability/deletion fights (Wikipedia model) |
| **Heat death** | Bounded communities exhaust their charter; maintenance mode → colony collapse |
| **Reuse friction** | Copy-paste HTML/DB content across sites is slow, lossy, attribution-prone |
| **Backend lock-in** | One engine, one storage model, one permission model |

Federation responses split along two axes:

1. **Where records live** — per-user site, per-instance repo, personal pod, mirrored git clone.
2. **How unity is achieved** — fork + spread, git push/pull, protocol activities, projection/cache, orchestrated union.

`shard-wiki` (per `INTENT.md`) targets axis (2) via an **orchestration layer**
over heterogeneous **shards**, with Git as coordination substrate — not a
single federation mechanism.

---

## 2. Federated Wiki (Smallest Federated Wiki / SFW)

### 2.1 Historical anchor

| Fact | Detail |
|------|--------|
| Origin | Ward Cunningham; launched at IndieWebCamp 2011 |
| Motivation | Regret that c2's 35,000+ pages lived on Ward's server, not contributors' |
| c2 migration | WikiWikiWeb moved to Federated Wiki ~2015 after read-only period |
| GitHub lineage | Fork button inspired by GitHub; "radical code sharing" as model |
| Current code | [github.com/fedwiki/wiki](https://github.com/fedwiki/wiki) (CoffeeScript; active releases through 2025) |

Ward's framing (Wired, 2012): the wiki's radical idea was an **edit button on
every page**; federated wiki's radical idea is a **fork button on every page**.

### 2.2 Inverted architecture

Traditional wiki vs federated wiki (Caulfield, NWACC 2014, summarizing Ward):

```
Traditional:  many people → one server → server owns records → consensus on server
Federated:    many people → many servers → each owns records → browser composes union
```

**Meaning is made in the browser.** The client pulls JSON page records from
multiple origins (CORS) and presents them as one navigable space. Consensus
emerges through **which versions spread** across the network, not through a
single server arbiter.

### 2.3 Page model (JSON + journal)

From [viki.wiki JSON schema](https://viki.wiki/json-schema.html):

```
page = { title, story, journal }
story = [ item ]           # paragraph-like plugin items
journal = [ action ]       # edit history that reconstructs story
action.type = create|add|move|edit|remove|fork
action.site = origin host  # present when content came from elsewhere
```

Key properties:

| Property | Implication |
|----------|-------------|
| **Data files, not DB render** | Fork copies JSON, not scraped HTML — reuse stays structured |
| **JSON items, not HTML** | Target site re-renders via plugins; display differences don't break remix |
| **Journal travels with page** | Attribution/history portable; no separate blame log |
| **Plugin architecture** | Item `type` selects renderer; missing plugins surfaced to user |
| **Fork action** | Whole-page copy from remote site into local site with provenance |
| **Item IDs preserved** | Stable anchors through edits; aliasing guards duplicate IDs |

### 2.4 Interaction patterns

| Pattern | Behavior |
|---------|----------|
| **Fork** | Copy remote page to your site; edit locally; original owner may merge back |
| **Drag-and-drop fork** | Cross-site page transfer in ~15 seconds (OER case) |
| **Chorus of voices** | Multiple versions of "same" topic coexist; linked, not merged by default |
| **Neighborhood / river** | Discovery via recent changes across federated sites (e.g. fedwikiriver.com) |
| **Happening** | Time-bounded collaborative event on a topic-specific subdomain/site |

### 2.5 Mike Caulfield — lifecycle and pedagogy

Caulfield articulated fedwiki's social model beyond Ward's mechanics:

**Kinneavy triangle / knowledge lifecycle** (composition theory):

| Phase | Mode | Typical medium | Fedwiki fit |
|-------|------|----------------|-------------|
| **I** | Personal capture | Notes, journal | Each person's site |
| **You** | Dialogic | Conversation, annotation | Fork chains, cross-site references |
| **It** | Expository | Stable shared article | Spread of refined forks |

Fedwiki supports **I → You → It** in one system; centralized wikis force **It**
(consensus) from the first edit.

**Bounded conversations / expected heat death** (2015):

- Wiki sites are **bounded conversations**, not permanent monuments.
- Sites are **expected to die**; valuable material is **forked into the next happening**.
- **Reverse bit-rot** — Smalltalk-era term Ward revived: objects/pages improve each
  time reused across systems (refactor on fork), defying entropy of abandoned forums.
- Contrast: colony collapse on centralized forums (Blue Hampshire example) vs
  humane site retirement with selective carry-forward.

**OER reuse** (2015): WordPress copy-paste ~10–15 min/page vs fedwiki fork ~15 sec;
bottleneck is software, not human willingness to remix.

**Dissent as feature** (Ogden via Wired): Wikipedia forces one perspective;
fedwiki enables multiple controversial pages, still linked for exploration.

### 2.6 Strengths and limits

| Strengths | Limits |
|-----------|--------|
| Personal sovereignty over pages | Requires running a site (mitigated by one-click AWS deploy) |
| Low-friction remix with provenance | Small niche ecosystem |
| Multi-perspective knowledge | Weak team-governance / permissions story vs enterprise wikis |
| JSON portability | Plugin fragmentation; non-Markdown item model |
| Strong conceptual clarity | Not a general adapter layer for arbitrary backends |

---

## 3. Other federation models

### 3.1 Git-backed distributed wikis (ikiwiki pattern)

[ikiwiki distributed wikis](https://ikiwiki.info/tips/distributed_wikis/) documents
a **spectrum of decentralization**:

| Level | Setup | Federation mechanism |
|-------|-------|---------------------|
| 0 | Single server | None |
| 1 | HTML mirror | Read-only copy |
| 2 | Split web + git host | Clone/pull |
| 3 | Pinger mirrors | Central bare repo + ping-on-edit propagation |
| 4 | Fully decentralized | Independent wikis push/pull via git to peers |

**Branching a wiki** = clone origin read-only (`git://`), edit locally without
push-back — explicit fork. Conflicts surface as markers in rendered pages.

**Relevance to shard-wiki:** Strong alignment with **Git-addressable
coordination** and **coordination journal** in `INTENT.md`. ikiwiki federates
*homogeneous* git-backed wikis; shard-wiki must also attach non-git shards
(Obsidian, WebDAV, Gitea wiki, Coulomb, etc.).

**Gollum / GitHub wikis:** Same backing-store idea — pages as files in a repo;
federation is git sync, not a wiki protocol. Multi-repo Gollum setups are
operational, not semantic union.

### 3.2 ActivityPub wiki federation (XWiki)

[XWiki ActivityPub Application](https://extensions.xwiki.org/xwiki/bin/view/Extension/ActivityPub%20Application/)
(v1.7.x) connects XWiki instances to the **fediverse**:

| Capability | Notes |
|------------|-------|
| Follow user / wiki actor | Receive Create/Update notifications |
| Share documents | Push page content to followers; view remote in modal |
| Messaging / discussions | Note objects threaded as discussions |
| Like, mention | Social engagement primitives |
| Webfinger + ActivityPub endpoints | Standard discovery |

**Caveats (documented by XWiki):** Federation "not well supported yet" for
full activity routing; Mastodon mention of Page entities incomplete; security
signing partial.

**Contrast with fedwiki:** ActivityPub federates **activities and notifications**
between **compatible app instances**; content may be copied on share, but the
model is social-graph + event stream, not per-user fork sovereignty. Closer to
**fediverse** than **fedwiki** UX.

**Contrast with shard-wiki:** ActivityPub could be an **adapter transport** for
some shards, but shard-wiki's core is wiki-page semantics (paths, links,
overlays, provenance), not activity streams.

### 3.3 Xanadu / transclusion lineage

Ted Nelson's [Project Xanadu](https://en.wikipedia.org/wiki/Project_Xanadu)
(1960s–) pursued **serious electronic literature** with patterns still relevant:

| Pattern | Intent | Modern partial implementations |
|---------|--------|-------------------------------|
| **Visible links** | Show destination context, not opaque jumps | Hover previews, Open Graph unfurls |
| **Parallel documents** | Side-by-side source + derivative | Multi-pane editors (Obsidian, Roam) |
| **Transclusion** | Live inclusion of remote span with origin pointer | Embeds, block references (weak) |
| **Transcopyright** | Permissioning for reuse | Mostly unsolved at web scale |
| **Stable addresses** | Fine-grained, durable pointers | Block UIDs (Roam); URL rot elsewhere |
| **Bi-directional links** | Backlinks as first-class | Obsidian, Roam, shard-wiki BackLinks UC |

Xanadu is **speculative design / pattern language**, not deployable federation.
Useful for shard-wiki **provenance, transclusion, and link resolution** thinking —
especially union BackLinks and projection freshness.

### 3.4 Personal / local-first wikis (TiddlyWiki, Obsidian)

Not federation protocols, but **sovereignty** models:

- **TiddlyWiki** — single-file portable wiki; complete user ownership.
- **Obsidian** — local vault + optional sync; community plugins for publish/remix.

Shard-wiki INTENT explicitly lists these as shard participants via adapters.
Federation is **attachment to a root information space**, not replacing the
local tool.

### 3.5 yawex multi-wiki resolution (cross-reference)

From `research/260608-yawex-prior-art/findings.md`:

| yawex state | Federation reading |
|-------------|-------------------|
| `REMOTE` | Jump to another wiki's page — remote shard navigation |
| `VIRTUAL` | Local processing, remote content — projection |
| Multi-wiki config | Multiple named wikis = multiple shards |

**Decision already recorded:** inspiration only; shard-wiki designs resolution
fresh for heterogeneous adapters.

### 3.6 Solid / personal data pods (brief)

Solid aims at **user-controlled pods** + linked data apps. Distributed wiki
discussions (forum threads, TiddlyWiki-on-Solid experiments) explore **personal
wikis on pods** vs **team commons**.

| Axis | Solid-style | Fedwiki | shard-wiki |
|------|-------------|---------|------------|
| Unit of sovereignty | Pod / user | Site / person | Shard |
| Unity mechanism | Linked data queries | Browser composition + fork | Orchestrated union + Git journal |
| Team wiki | Secondary; app-dependent | Weak | Supported via shards + authz |

No mature Solid wiki federation standard emerged; treat as **adjacent personal-
data sovereignty** research, not direct prior art.

---

## 4. Comparison matrix

| Model | Unit of ownership | Unity mechanism | Consensus model | History / provenance | Heterogeneous backends |
|-------|-------------------|-----------------|-----------------|----------------------|------------------------|
| **Centralized wiki** (c2, MediaWiki) | Site operator | Single namespace | On-page consensus | Server revision log | No |
| **Federated Wiki** | Per-site (per person) | Browser pulls JSON; fork | Spread of versions | Journal per page | No (all SFW-shaped) |
| **ikiwiki distributed** | Per git clone | git push/pull, pingers | Merge conflicts in git | Git commits | No (all ikiwiki) |
| **ActivityPub (XWiki)** | Per instance | Activity stream | Social follow/share | Activity + page store | No (XWiki only) |
| **Xanadu** | Document address | Transclusion | Parallel versions | Version trails (concept) | N/A (unbuilt) |
| **shard-wiki (INTENT)** | Per shard | Orchestrator union | Configurable policy | Git coordination journal + shard history | **Yes** (adapter contract) |

---

## 5. Glossary (federation track)

| Term | Meaning | Primary source |
|------|---------|----------------|
| **Fork** | Copy a page (or site branch) to a new home; divergent editing | Fedwiki, git |
| **Journal** | Ordered actions reconstructing page state; travels with page | Fedwiki JSON schema |
| **Story** | Array of typed items (paragraph, image, …) forming page body | Fedwiki |
| **Happening** | Time-bounded fedwiki collaboration on a topic site | Caulfield |
| **Bounded conversation** | Site with expected end; not infinite commons | Caulfield |
| **Reverse bit-rot** | Content improves through reuse across contexts | Caulfield / Ward |
| **Chorus of voices** | Multiple perspectives on same topic, linked | Ward |
| **Inverted model** | Records distributed; meaning composed client-side | Ward |
| **Projection** | Local view of remote content without claiming ownership | shard-wiki / yawex VIRTUAL |
| **Overlay** | Local edit against remote/canonical without immediate mutation | shard-wiki |
| **Shard** | Independently meaningful page store with own capabilities | shard-wiki |
| **Coordination journal** | Git-backed change record for an information space | shard-wiki |
| **Transclusion** | Include live span from elsewhere with origin visible | Xanadu |
| **Fediverse** | Network of ActivityPub-speaking apps | XWiki AP, Mastodon |
| **Pinger / pingee** | Edit-triggered mirror refresh between ikiwiki sites | ikiwiki |
| **Wiki actor** | Entire wiki as ActivityPub actor | XWiki AP |

---

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

### 6.1 Strong resonances

| Fedwiki / federation idea | shard-wiki concept | Notes |
|---------------------------|-------------------|-------|
| Personal ownership of edits | Shard sovereignty | shard-wiki generalizes beyond per-person sites |
| Fork with provenance | Overlay + patch flows | shard-wiki separates draft from destructive apply |
| Journal / history with page | Coordination journal + shard revision | Git journal is space-level; shard retains own history |
| Browser-composed union | Union of pages across shards | Orchestrator presents coherent graph |
| JSON not HTML for remix | Markdown-first page model | Different format; same structural intent |
| Lazy pull from remote | Projection | yawex VIRTUAL; explicit freshness |
| Chorus of voices | Union without erasure | Show provenance, divergence, equivalents |
| Bounded conversation | Configurable policy | Mechanism not policy — space may be permanent or ephemeral |
| Reverse bit-rot on reuse | Reconciliation / sync | Policy-driven; not automatic fork |
| Derived views (recent, links) | UC-05 union views | BackLinks, RecentChanges across shards |

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

| Fedwiki assumption | shard-wiki correction |
|--------------------|----------------------|
| Every participant runs SFW-shaped JSON site | **Adapter contract** for Gitea, folders, Obsidian, WebDAV, engines |
| Fork = default edit primitive | **Capability-aware**: read-only shards need overlay, not fork |
| Client composes in browser only | Orchestrator may serve CLI, agents, CI — not browser-only |
| Per-site = per-person | Shards may be team repos, org wikis, app databases |
| No central coordination | **Git-addressable coordination layer** per information space |
| Plugin item types | Markdown-first; engine-specific render is out of core scope |
| Implicit spread-as-consensus | **Mechanism over policy** — canonical source is explicit config |

### 6.3 What shard-wiki adds beyond fedwiki

1. **Heterogeneous attachment** — not all shards speak the same page JSON.
2. **Capability matrix** — read/write/diff/merge/lock/publish per shard.
3. **Overlay-before-mutation** — respect remote sovereignty and limited backends.
4. **Semantic wiki sync** — not generic file mirroring.
5. **Enterprise authz ladder** — L0 open → delegated IAM (without owning identity).
6. **Divergence detection** — equivalent pages across shards, reconcilable.

### 6.4 What fedwiki teaches that shard-wiki should not lose

1. **Frictionless reuse** — if remix takes 15 minutes, federation fails socially.
2. **Provenance by default** — history must travel or be reconstructible.
3. **Multi-perspective truth** — union ≠ single canonical article.
4. **Expected lifecycle** — information spaces may be ephemeral; plan for carry-forward.
5. **Personal sovereignty** — contributors must not be hostage to one operator's server.

---

## 7. Use-case promotion (done 2026-06-08)

Promoted to `spec/UseCaseCatalog.md` as UC-26–UC-33. Architecture decisions
tracked in `workplans/SHARD-WP-0002-federation-architecture.md`.

| Research ID | Catalog UC |
|-------------|------------|
| UC-FED-01 Fork page from remote shard | UC-26 |
| UC-FED-02 View multiple versions of equivalent page | UC-27 |
| UC-FED-03 Carry forward from closed/archived shard | UC-28 |
| UC-FED-04 Remix with portable attribution | UC-29 |
| UC-FED-05 Time-bounded collaboration space | UC-30 |
| UC-FED-06 Subscribe to remote shard changes | UC-31 |
| UC-FED-07 Transclude remote span | UC-32 |
| UC-FED-08 Git-branch information space | UC-33 |

---

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

1. **Fork vs overlay vs import** — When does shard-wiki copy content into a
   writable shard vs keep an overlay vs link-only reference?
2. **Equivalent page identity** — How are "same topic" pages matched across
   shards (title, path, link graph, explicit alias)?
3. **Journal format** — Does shard-wiki adopt fedwiki-like action journals,
   Git commits only, or both per shard type?
4. **Browser vs server composition** — Where does union merging run for agents
   and non-UI consumers?
5. **ActivityPub as adapter** — Optional transport for change notification, or
   out of scope?
6. **Ephemeral spaces** — Should information spaces have first-class lifecycle
   (archived, read-only, merged-into-successor)?
7. **Plugin/item extensibility** — Markdown extensions vs structured blocks for
   remixable assessments (fedwiki OER lesson)?
8. **Consensus without erasure** — Policy presets: fedwiki-spread, git-merge,
   designated canonical shard, vote-to-merge?

---

## 9. Sources

| Source | URL |
|--------|-----|
| Wikipedia — Federated Wiki | https://en.wikipedia.org/wiki/Federated_Wiki |
| Wired — Wiki Inventor Sticks a Fork | https://www.wired.com/2012/07/wiki-inventor/ |
| viki.wiki — JSON Schema | https://viki.wiki/json-schema.html |
| Fedwiki GitHub | https://github.com/fedwiki/wiki |
| Caulfield — Federated Education (NWACC 2014) | https://hapgood.us/2014/11/06/federated-education-new-directions-in-digital-collaboration/ |
| Caulfield — Bounded Conversations | https://hapgood.us/2015/01/21/rethinking-wiki-lifecycle-sites-as-bounded-conversations/ |
| Caulfield — OER Case for Federated Wiki | https://hapgood.us/2015/05/05/the-oer-case-for-federated-wiki/ |
| ikiwiki — distributed wikis | https://ikiwiki.info/tips/distributed_wikis/ |
| XWiki — ActivityPub Application | https://extensions.xwiki.org/xwiki/bin/view/Extension/ActivityPub%20Application/ |
| Maggie Appleton — Xanadu Patterns | https://maggieappleton.com/xanadu-patterns |
| Wikipedia — Project Xanadu | https://en.wikipedia.org/wiki/Project_Xanadu |
| shard-wiki — yawex prior art | `research/260608-yawex-prior-art/findings.md` |
| shard-wiki — c2 origins | `research/260608-c2-wiki-origins/findings.md` |
| shard-wiki — INTENT | `INTENT.md` |

---

## 10. Traceability

| This document section | Informs (future) |
|-----------------------|------------------|
| §2 Federated Wiki | Adapter design, page model, overlay/fork policy |
| §3.1 ikiwiki | Git coordination journal, mirror/branch modes |
| §3.2 ActivityPub | Optional notification adapter |
| §3.3 Xanadu | Link resolution, transclusion, provenance UI |
| §6 Mapping | Architecture blueprint guardrails |
| §7 UC seeds | `spec/UseCaseCatalog.md` promotion pass |