generated from coulomb/repo-seed
research: Federated Wiki deep dive (journal/fork/neighborhood); UC-70-72
SHARD-WP-0003 T1. Federation model (not a shard candidate): per-page append-only semantic-action journal with story as derived replay, fork-with-site-provenance, neighborhood/roster discovery + chorus of forks. Prior art for shard-wiki's own pillars: coordination journal (UC-71), overlay-before-mutation (UC-26 fork), union-without-erasure (UC-72). Attach as REST/file-store hybrid (page JSON + CORS, UC-70). Feeds SHARD-WP-0002 T1-T5, T11, T13, T16. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
21
.claude/ralph-loop.local.md
Normal file
21
.claude/ralph-loop.local.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
active: true
|
||||
iteration: 1
|
||||
session_id: b24b53ca-a25b-4a18-8331-925c4100d39f
|
||||
max_iterations: 20
|
||||
completion_promise: "HEUREKA"
|
||||
workplan_id: SHARD-WP-0003
|
||||
workplan_file: workplans/SHARD-WP-0003-engine-dives-batch.md
|
||||
started_at: "2026-06-14T16:37:36Z"
|
||||
---
|
||||
|
||||
Read the workplan at `workplans/SHARD-WP-0003-engine-dives-batch.md`.
|
||||
|
||||
If every task has `status: done` AND frontmatter `status: done`:
|
||||
run `rm -f .claude/ralph-loop.local.md` first (deactivates the loop so the stop hook exits cleanly),
|
||||
then output <promise>HEUREKA</promise>.
|
||||
|
||||
Otherwise implement the next `todo` task as described in the workplan.
|
||||
Set task `in_progress` when starting, `done` when complete.
|
||||
When all tasks are done set frontmatter `status: done`.
|
||||
|
||||
4
SCOPE.md
4
SCOPE.md
@@ -19,9 +19,9 @@ Learnings update both SCOPE and INTENT where necessary.
|
||||
|-------|-------|
|
||||
| Code | Python package scaffold (`src/shard_wiki/`, smoke tests only) |
|
||||
| Intent | `INTENT.md` established; authorization-in-core amendments drafted |
|
||||
| Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (`research/260608-*/`); XWiki/TWiki/Foswiki deep dives (`research/260613-*/`); Xanadu + ZigZag + Roam + Obsidian + Notion + Joplin + Logseq + local-first workspaces (Anytype/AFFiNE/AppFlowy) + Trilium + Wiki.js deep dives & shard-spectrum synthesis (`research/260614-*/`) |
|
||||
| Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (`research/260608-*/`); XWiki/TWiki/Foswiki deep dives (`research/260613-*/`); Xanadu + ZigZag + Roam + Obsidian + Notion + Joplin + Logseq + local-first workspaces (Anytype/AFFiNE/AppFlowy) + Trilium + Wiki.js + Federated Wiki deep dives & shard-spectrum synthesis (`research/260614-*/`) |
|
||||
| Demand | NetKingdom integration asks captured, not yet negotiated |
|
||||
| Spec | Architecture blueprint drafted; UseCaseCatalog 69 UCs from research; PRD/TSD scaffolds |
|
||||
| Spec | Architecture blueprint drafted; UseCaseCatalog 72 UCs from research; PRD/TSD scaffolds |
|
||||
| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (16 tasks: T1–T10 federation + T11–T16 adapter contract); `SHARD-WP-0003` active (9 engine dives); `SHARD-WP-0004` active (8 computational-knowledge dives) |
|
||||
|
||||
## In Scope (today)
|
||||
|
||||
20
research/260614-federated-wiki-deep-dive/README.md
Normal file
20
research/260614-federated-wiki-deep-dive/README.md
Normal file
@@ -0,0 +1,20 @@
|
||||
# 260614 — Federated Wiki deep dive
|
||||
|
||||
Deep dive on Ward Cunningham's **Federated Wiki** (Smallest Federated Wiki / SFW,
|
||||
2011 →) as a **federation model** rather than a single shard: fork-with-provenance,
|
||||
the per-page **JSON journal** of semantic actions, the **story** of typed items, the
|
||||
**neighborhood/roster** discovery model, and time-bounded **happenings**.
|
||||
|
||||
This is prior art for shard-wiki's **coordination layer itself** — the closest existing
|
||||
system to "a union of pages preserving provenance, assembled non-destructively." It
|
||||
extends `research/260608-federation-concepts/` §3 with the concrete data model + protocol.
|
||||
|
||||
- `findings.md` — full writeup: data model, journal/action types, federation protocol,
|
||||
capability profile, INTENT mapping, UC seeds (UC-70–UC-72), architecture notes for
|
||||
SHARD-WP-0002, open questions, sources, traceability.
|
||||
|
||||
Catalog yield: UC-70 (attach a fedwiki site via page-JSON + CORS), UC-71 (append-only
|
||||
semantic action journal with site provenance as a coordination-journal model), UC-72
|
||||
(fork-with-site-provenance federation across a neighborhood / chorus). Enriched
|
||||
UC-26/28/30/05/27. Feeds SHARD-WP-0002 T1–T5 (federation) and T11/T13/T16 (write
|
||||
granularity, log-based merge, identity≠placement).
|
||||
240
research/260614-federated-wiki-deep-dive/findings.md
Normal file
240
research/260614-federated-wiki-deep-dive/findings.md
Normal file
@@ -0,0 +1,240 @@
|
||||
# Federated Wiki — deep dive (findings)
|
||||
|
||||
**Date:** 2026-06-14 · **Source:** SHARD-WP-0003 T1 · **Subject:** Ward Cunningham's
|
||||
Smallest Federated Wiki (SFW) / Federated Wiki (fedwiki ecosystem).
|
||||
|
||||
## Why this dive
|
||||
|
||||
Every prior dive has been a *shard candidate* — a store we might attach. Federated Wiki
|
||||
is different: it is a **federation model**, the one piece of public prior art whose core
|
||||
job is the same as shard-wiki's coordination layer — *present a union of pages from many
|
||||
independent sites while preserving where each came from, and let people copy and edit
|
||||
non-destructively*. Ward Cunningham (inventor of the wiki) built SFW in 2011 precisely to
|
||||
fix the original wiki's single-canonical-page weakness with **fork + provenance**. We go
|
||||
past the surface (`260608-federation-concepts/` §3) into the data model and protocol, then
|
||||
ask what shard-wiki should adopt.
|
||||
|
||||
**Framing:** fedwiki is not just "a shard we attach" — it is a *worked example of the
|
||||
coordination journal, overlay-before-mutation, and union-without-erasure*, three of our
|
||||
own design pillars, shipped and running.
|
||||
|
||||
---
|
||||
|
||||
## 1. The data model — page = title + story + journal
|
||||
|
||||
A fedwiki page is a small JSON object with three core fields (plus optional decoration):
|
||||
|
||||
```json
|
||||
{
|
||||
"title": "Welcome Visitors",
|
||||
"story": [
|
||||
{ "type": "paragraph", "id": "7b56f22a4b9ee974",
|
||||
"text": "Welcome to this [[Federated Wiki]] site." },
|
||||
{ "type": "image", "id": "a1c0e3...", "url": "...", "caption": "..." }
|
||||
],
|
||||
"journal": [
|
||||
{ "type": "create", "id": "7b56f22a4b9ee974", "item": {...}, "date": 1310000000000 },
|
||||
{ "type": "add", "id": "a1c0e3...", "item": {...}, "after": "7b56f22a4b9ee974",
|
||||
"date": 1310000100000 },
|
||||
{ "type": "edit", "id": "7b56f22a4b9ee974", "item": {...}, "date": 1310000200000 },
|
||||
{ "type": "fork", "site": "ward.fed.wiki.org", "date": 1310000300000 }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- **story** — an *ordered array of typed items* ("paragraph-like" items). Each item is
|
||||
`{ type, id, text, ...type-specific }`. The **`id`** is a random 16-hex string,
|
||||
**stable across edits** (it is the unit of identity within a page). The **`type`** names
|
||||
the **plugin** that renders/edits the item (`paragraph`, `image`, `html`, `markdown`,
|
||||
`code`, `method`, `pagefold`, chart plugins, …). *Data lives in the item; behavior lives
|
||||
in the plugin* — the item is portable JSON; the plugin is the renderer.
|
||||
- **journal** — an *ordered, append-only array of action objects* that, when replayed,
|
||||
**reconstructs the story**. The story is a materialized view of the journal. This is the
|
||||
key architectural choice: **the journal is the source of truth, the story is derived.**
|
||||
|
||||
## 2. Journal action types — a semantic op-log
|
||||
|
||||
Each journal entry is an action with `{ type, ... , date }` (epoch-ms). The action types:
|
||||
|
||||
| action | fields | meaning |
|
||||
|---------|--------|---------|
|
||||
| `create`| `id, item, date` | first item — page born |
|
||||
| `add` | `id, item, after, date` | insert an item after another |
|
||||
| `edit` | `id, item, date` | replace an item's content (id preserved) |
|
||||
| `move` | `order, date` | reorder items |
|
||||
| `remove`| `id, date` | delete an item |
|
||||
| `fork` | `site, date` | **mark that the page was copied from `site` at this point** |
|
||||
|
||||
Two things matter for us:
|
||||
|
||||
1. **These are *semantic* operations** (add/move/edit/remove a paragraph), not text diffs
|
||||
and not character-level CRDT ops. The write granularity is the **story item
|
||||
(paragraph)** — a *middle* granularity between whole-file (TiddlyWiki) and
|
||||
block/character (Logseq/CRDT). It is an **op-log** like a CRDT, but the ops are
|
||||
coarse-grained and **applied by humans via fork**, not auto-merged.
|
||||
2. **`fork` is the provenance primitive.** When you copy a remote page to your own site,
|
||||
a `fork` entry is appended recording the **source site** and time. The journal of a
|
||||
forked page therefore **serializes a directed acyclic graph (DAG)** of where content
|
||||
came from — "the journal of a forked page is detailed enough to recognize where in the
|
||||
journal of the original the fork took place" (CouchDB-style per-entry sequence numbers
|
||||
make the cut-point identifiable). History visualization highlights the forked entry.
|
||||
|
||||
## 3. The federation protocol — sites, neighborhood, roster
|
||||
|
||||
- **Site** = an independent server (originally Node.js; also static-file and serverless
|
||||
variants). A site owns a set of pages, each served as **page JSON over HTTP** at
|
||||
`/<slug>.json`, with **CORS headers** so a *browser-side* client can fetch pages from
|
||||
**any** site. Page identity within a site is the **slug** (a title-derived kebab name).
|
||||
- **The client assembles the union, not the server.** The fedwiki client ("the lineup")
|
||||
renders pages **side by side**: clicking a link opens that page *from whatever site it
|
||||
resolves against*, appended to the right. Browsing literally builds a left-to-right
|
||||
trail across sites.
|
||||
- **Neighborhood** = the dynamic set of sites encountered in the current session (from the
|
||||
sites of pages you've opened, links, and forks). **Search runs across the neighborhood**
|
||||
— a federated search over exactly the sites you've touched.
|
||||
- **Roster** = an explicit, authored list of sites to include (a curated neighborhood);
|
||||
"sister sites" are peers you watch. There is **no central registry** — discovery is by
|
||||
link, fork, and roster.
|
||||
- **Happenings** = time-bounded collaborative events where many participants fork around a
|
||||
topic for a period, producing a burst of related forks (a bounded collaboration that
|
||||
leaves a durable forked record on each participant's own site).
|
||||
|
||||
## 4. The editorial model — fork, don't edit-in-place
|
||||
|
||||
You can only write to **your own** site. To change someone else's page you **fork** it
|
||||
(copy into your site, journal records the source), then edit your copy. Many forks of the
|
||||
same page coexist across sites — Cunningham's **"chorus of voices"**: *no canonical
|
||||
version*, divergence is normal and visible, and you choose whose changes to pull by forking
|
||||
them. There is **no automatic merge** — reconciliation is human: compare journals, fork the
|
||||
version you prefer, optionally re-fork upstream changes.
|
||||
|
||||
---
|
||||
|
||||
## 5. Capability profile
|
||||
|
||||
| Dimension (synthesis spectrum) | Federated Wiki |
|
||||
|--------------------------------|----------------|
|
||||
| Attachment mode | **REST/file-store hybrid** — page JSON over HTTP+CORS; also static files |
|
||||
| Addressing granularity | **story item (paragraph)** via stable 16-hex `id` |
|
||||
| Content identity | item `id` random+stable; page id = site + slug |
|
||||
| Identity vs placement | **placement-bound**: identity = `site` + `slug`; forks are *new* identities linked by journal provenance |
|
||||
| Structure | ordered array of **typed items** (plugin-typed) |
|
||||
| History | **per-page append-only journal** of semantic actions (op-log) |
|
||||
| Merge model | **fork + manual journal compare** — a *third model* beside git 3-way and CRDT auto-merge |
|
||||
| Native query | none built-in; **neighborhood search** (federated full-text across touched sites) |
|
||||
| Translation | item `text` is wiki/Markdown-ish; plugins own their formats |
|
||||
| Attachment/write granularity | **story-item level** (add/edit/move/remove one item) |
|
||||
| Operational envelope | tiny servers, browser-driven; CORS is the whole API surface |
|
||||
| Access grant | **own-site-only writes**; reads open via CORS |
|
||||
| Content opacity | transparent JSON (no E2EE); plugin-typed but inspectable |
|
||||
| Provenance | **first-class** — `fork` records source site; journal = provenance DAG |
|
||||
|
||||
## 6. INTENT mapping
|
||||
|
||||
### Reinforcements (fedwiki validates our pillars)
|
||||
|
||||
- **Coordination journal** (INTENT) ≈ fedwiki **journal**. Our journal idea is *exactly*
|
||||
fedwiki's per-page append-only action log — and fedwiki proves the story-as-derived-view
|
||||
pattern works. Strong reinforcement; adopt the **semantic-op + provenance-entry** shape.
|
||||
- **Overlay before mutation** ≈ **fork**. Fork *is* the canonical overlay: a
|
||||
non-destructive copy onto a writable surface, recording provenance, before any change.
|
||||
- **Union without erasure** ≈ **neighborhood + chorus**. The union is assembled from many
|
||||
sovereign sites; provenance (which site, forked-from) is never hidden; divergence is
|
||||
surfaced, not resolved away.
|
||||
- **No silent remote mutation** ≈ **own-site-only writes**. You structurally *cannot*
|
||||
mutate a remote; you fork to your own site. This is our rule, enforced by architecture.
|
||||
- **Mechanism over policy** ≈ **no canonical source**. Fedwiki ships the mechanism (fork,
|
||||
journal, neighborhood) and leaves "which version wins" entirely to people.
|
||||
- **Graceful degradation** ≈ static-file sites — a fedwiki site can be a read-only pile of
|
||||
JSON files; still forkable, still in the neighborhood.
|
||||
|
||||
### Divergences (boundaries / design notes, not bugs)
|
||||
|
||||
- **Identity = placement.** Fedwiki page identity is `site` + `slug`; a fork is a *new*
|
||||
page whose only tie to the origin is a journal `fork` entry. shard-wiki wants
|
||||
**identity ≠ placement** (the "same" page across shards under a stable identity, T16) —
|
||||
so we treat fedwiki's journal-linked forks as *provenance edges*, and layer our own
|
||||
cross-shard identity over them rather than adopting slug-as-identity.
|
||||
- **No query / no typed-record model.** Fedwiki is paragraphs+plugins, not a typed DB
|
||||
(contrast Notion/Wikibase). Fine — it sits at the *coordination* end, not the structure
|
||||
end. We don't ask fedwiki to provide query; the neighborhood search is the model for
|
||||
*federated* search across shards (T-federation), not in-shard query.
|
||||
- **Browser-assembles-union.** Fedwiki pushes union assembly to the client. shard-wiki
|
||||
assembles server/orchestrator-side. Adopt the *model* (union from sovereign sources +
|
||||
provenance), not the client-only locus.
|
||||
|
||||
### What to keep
|
||||
|
||||
1. **Journal = append-only semantic-op log with provenance entries**, story = derived
|
||||
replay view. This is the concrete shape for our coordination journal (T13).
|
||||
2. **Fork-with-source-attribution** as the overlay/adopt primitive across shards.
|
||||
3. **Neighborhood** as the model for a *dynamic, link-and-fork-discovered* federated set +
|
||||
search, with **roster** as the curated/explicit variant.
|
||||
4. **Chorus of forks** — represent divergent versions across shards as co-equal, linked by
|
||||
provenance, with reconciliation as an explicit human/policy step (mechanism over policy).
|
||||
|
||||
---
|
||||
|
||||
## 7. UC seeds
|
||||
|
||||
| # | Seed | Disposition |
|
||||
|---|------|-------------|
|
||||
| UC-70 | Attach a Federated Wiki site as a shard via its **page JSON + CORS** (REST/file-store hybrid); project pages, fork to overlay | **new** |
|
||||
| UC-71 | Adopt a **per-page append-only semantic-action journal with provenance entries** (fork=source site) as the coordination-journal model — replay to materialize, compare to locate divergence | **new** |
|
||||
| UC-72 | **Fork-with-site-provenance federation across a neighborhood** of peer shards — assemble a union from links/forks, search across it, preserve the chorus without forcing a canonical | **new** |
|
||||
| — | fork-with-provenance as overlay/adopt | enrich **UC-26** (fork) |
|
||||
| — | carry-forward of forked content + upstream re-fork | enrich **UC-28** (carry-forward) |
|
||||
| — | happenings = time-bounded collaboration leaving durable forks | enrich **UC-30** (time-bounded space) |
|
||||
| — | union/chorus of co-equal versions, provenance-linked | enrich **UC-05 / UC-27** |
|
||||
|
||||
## 8. Architecture notes for SHARD-WP-0002
|
||||
|
||||
- **T1–T5 (federation):** fedwiki is the reference design. The **journal** (append-only,
|
||||
semantic ops, fork-provenance) is the concrete coordination-journal shape; **neighborhood
|
||||
+ roster** is the discovery/membership model (dynamic vs curated); **fork** is the
|
||||
overlay/adopt op. Model the union as an assembly over sovereign sources with provenance
|
||||
edges, reconciliation left to policy.
|
||||
- **T11 (capability/write-granularity):** add **story-item / paragraph** as a named
|
||||
write-granularity tier between whole-file and block/character.
|
||||
- **T13 (history portability / merge model):** record fedwiki's **journal-replay op-log**
|
||||
as a *third merge model* beside git 3-way and CRDT auto-merge — a **coarse semantic
|
||||
op-log applied manually via fork**. A shard whose history *is* such a journal can supply
|
||||
our coordination journal almost directly (vs git-commit import or CRDT-update import).
|
||||
- **T16 (identity ≠ placement):** fedwiki's `fork` journal entries are **provenance edges**
|
||||
between same-named pages on different sites — exactly the cross-shard "same page,
|
||||
different placement" relation we must model. Use them as edges; keep our own identity
|
||||
layer above slug.
|
||||
|
||||
## 9. Open questions
|
||||
|
||||
1. Should shard-wiki's coordination journal adopt fedwiki's **exact action vocabulary**
|
||||
(create/add/edit/move/remove/fork) at the page-item level, or a more granular/abstract
|
||||
op set that other shards can also emit?
|
||||
2. Is **neighborhood** (dynamic, link/fork-discovered) a first-class membership mode for an
|
||||
information space, or only a *view* over an explicitly-configured shard set (roster)?
|
||||
3. How do we reconcile fedwiki's **slug-as-identity + fork-DAG** with our intended
|
||||
**stable cross-shard identity** (T16) — promote fork edges into the identity graph, or
|
||||
keep them as provenance-only annotations?
|
||||
4. Does the **chorus / no-canonical** stance compose with shards that *do* assert a
|
||||
canonical (Notion, an upstream git main)? (policy-selectable canonical over a
|
||||
mechanism that permits chorus.)
|
||||
|
||||
## 10. Sources
|
||||
|
||||
- Smallest Federated Wiki wiki: **Story JSON**, **Federation Details** —
|
||||
github.com/WardCunningham/Smallest-Federated-Wiki/wiki
|
||||
- JSON Schema notes — song.fed.wiki.org/json-schema.html
|
||||
- "Smallest Federated Wiki" — home.c2.com/smallest-federated-wiki.html
|
||||
- Federated Wiki — federated.wiki (Visualizing Page History)
|
||||
- Mike Caulfield, "The OER Case for Federated Wiki" — hapgood.us (2015)
|
||||
- Jon Udell, "A federated Wikipedia" — blog.jonudell.net (2015)
|
||||
- Wikipedia: *Federated Wiki*; IndieWeb: *Smallest Federated Wiki*
|
||||
- fedwiki/wiki-plugin-transport (plugin/transport reference)
|
||||
- prior: `research/260608-federation-concepts/` §3
|
||||
|
||||
## 11. Traceability
|
||||
|
||||
New UCs **UC-70–UC-72** carry the marker **⊞** in the wikiengines column of
|
||||
`spec/UseCaseCatalog.md` (true lineage = this dive; placed in the nearest existing column).
|
||||
Enriched: UC-26, UC-28, UC-30, UC-05, UC-27. Architecture cross-refs: SHARD-WP-0002
|
||||
T1–T5, T11, T13, T16.
|
||||
@@ -28,3 +28,4 @@ when multiple files or sources are involved. Findings here inform `spec/` and
|
||||
| 2026-06-14 | `260614-localfirst-workspaces-deep-dive/` | Anytype · AFFiNE · AppFlowy — CRDT local-first workspaces (any-sync/Yjs/Yrs), native merge, P2P/E2EE; UC-64/65 |
|
||||
| 2026-06-14 | `260614-trilium-deep-dive/` | Trilium/TriliumNext — note cloning (DAG hierarchy), attribute inheritance/templates, HTML-native, scripting+ETAPI; UC-66/67 |
|
||||
| 2026-06-14 | `260614-wikijs-deep-dive/` | Wiki.js — storage-module engine (DB↔Git Markdown), GraphQL API, pluggable modules ≈ adapter-contract prior art; UC-68/69 |
|
||||
| 2026-06-14 | `260614-federated-wiki-deep-dive/` | Federated Wiki — fork-with-provenance, per-page semantic-action journal (story=replay), neighborhood/roster + chorus; prior art for our coordination journal / overlay / union pillars; UC-70/71/72 |
|
||||
@@ -11,7 +11,8 @@ Promoted from `research/260608-c2-wiki-origins/`,
|
||||
`research/260614-notion-deep-dive/`, `research/260614-joplin-deep-dive/`,
|
||||
`research/260614-logseq-deep-dive/`,
|
||||
`research/260614-localfirst-workspaces-deep-dive/`,
|
||||
`research/260614-trilium-deep-dive/`, and `research/260614-wikijs-deep-dive/`.
|
||||
`research/260614-trilium-deep-dive/`, `research/260614-wikijs-deep-dive/`, and
|
||||
`research/260614-federated-wiki-deep-dive/`.
|
||||
See InfoTechPrimers on coulomb.social for use-case catalog conventions.
|
||||
|
||||
## Conventions
|
||||
@@ -121,7 +122,11 @@ seed, or writable copy per policy — distinct from UC-04 (overlay without copy)
|
||||
and UC-03 (projection only). Fork vs overlay vs import decided in
|
||||
`SHARD-WP-0002`. Should record a **created-from genealogy edge** in the coordination
|
||||
journal so the lineage is navigable as a dimension (UC-49,
|
||||
`research/260614-zigzag-deep-dive/findings.md` §9).
|
||||
`research/260614-zigzag-deep-dive/findings.md` §9). The fedwiki deep dive details the
|
||||
concrete shape: fork is **own-site-only write + a `fork` journal entry recording the source
|
||||
site**, and a forked journal stays **detailed enough to locate the upstream cut-point**
|
||||
(`research/260614-federated-wiki-deep-dive/findings.md` §2, §4) — enabling later
|
||||
carry-forward/re-fork (UC-28) and modelling the genealogy edge as **provenance** (UC-71/72).
|
||||
**Priority:** Later
|
||||
|
||||
### UC-27 — View multiple versions of equivalent page
|
||||
@@ -910,6 +915,58 @@ sub-mode beside Notion's REST.
|
||||
|
||||
---
|
||||
|
||||
### UC-70 — Attach a Federated Wiki site as a shard (page JSON + CORS)
|
||||
|
||||
**Actor:** Orchestrator / adapter
|
||||
**Goal:** Attach a **Federated Wiki** site as a shard via its **page JSON** served over
|
||||
**HTTP with CORS** (`/<slug>.json`); project its pages and **fork** them to overlay
|
||||
non-destructively.
|
||||
**Source:** federation, intent
|
||||
**Notes:** A fedwiki site is a sovereign server (Node.js, static-file, or serverless)
|
||||
serving `{ title, story[], journal[] }` page JSON
|
||||
(`research/260614-federated-wiki-deep-dive/findings.md` §1, §3). A **REST/file-store
|
||||
hybrid** attachment mode: CORS-readable JSON over HTTP, or a static pile of `.json` files.
|
||||
Writes are **own-site-only** — to change a remote page you **fork** it (UC-26), so this
|
||||
shard is naturally a read/project + overlay target, never silent remote mutation. Feeds
|
||||
SHARD-WP-0002 T14 (attachment mode), T11 (capability profile).
|
||||
**Priority:** Later
|
||||
|
||||
### UC-71 — Coordination journal as an append-only semantic-action log with provenance
|
||||
|
||||
**Actor:** Core orchestrator
|
||||
**Goal:** Model the coordination journal as a **per-page append-only log of semantic
|
||||
actions** (`create`/`add`/`edit`/`move`/`remove`/`fork`) carrying **provenance entries**
|
||||
(fork records the source site), with the page state **derived by replaying** the log and
|
||||
divergence **located by comparing** logs.
|
||||
**Source:** federation, intent
|
||||
**Notes:** Directly adopts the fedwiki **journal** shape — the story is a materialized
|
||||
view of the journal, fork entries serialize a **provenance DAG**, and per-entry sequence
|
||||
numbers make the fork cut-point identifiable
|
||||
(`research/260614-federated-wiki-deep-dive/findings.md` §2, §6). This is concrete prior art
|
||||
for INTENT's coordination journal: a **third merge model** beside git 3-way and CRDT
|
||||
auto-merge — a coarse semantic op-log applied manually via fork. Feeds SHARD-WP-0002 T13
|
||||
(history portability / merge model) and T1–T5 (federation).
|
||||
**Priority:** Later
|
||||
|
||||
### UC-72 — Federate by fork-with-provenance across a neighborhood / chorus
|
||||
|
||||
**Actor:** Reader / curator
|
||||
**Goal:** Assemble a **union from sovereign peer shards** discovered by **link and fork**
|
||||
(a *neighborhood*) or by an explicit **roster**, **search across that set**, and preserve a
|
||||
**chorus of co-equal, provenance-linked versions** without forcing a canonical — pulling
|
||||
another's changes by forking them.
|
||||
**Source:** federation, intent
|
||||
**Notes:** Fedwiki's neighborhood (dynamic, link/fork-discovered) vs roster (curated)
|
||||
membership and "chorus of voices" no-canonical stance
|
||||
(`research/260614-federated-wiki-deep-dive/findings.md` §3, §4) model
|
||||
**union-without-erasure** at the coordination layer: divergence is normal and visible,
|
||||
reconciliation is an explicit human/policy step (mechanism over policy). Open: does a
|
||||
chorus compose with shards that assert a canonical? Feeds SHARD-WP-0002 T1–T5; relates
|
||||
UC-05/UC-27 (union/chorus), UC-26 (fork).
|
||||
**Priority:** Later
|
||||
|
||||
---
|
||||
|
||||
## B. Knowledge work and collaboration
|
||||
|
||||
*Patterns from c2 social conventions and yawex authoring workflows.*
|
||||
@@ -1170,6 +1227,9 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD.
|
||||
| UC-67 | | | | ⊕ | ✓ |
|
||||
| UC-68 | | | | ⚓ | ✓ |
|
||||
| UC-69 | | | | ⚓ | ✓ |
|
||||
| UC-70 | | | ✓⊞ | | ✓ |
|
||||
| UC-71 | | | ✓⊞ | | ✓ |
|
||||
| UC-72 | | | ✓⊞ | | ✓ |
|
||||
| UC-08 | ✓ | | |
|
||||
| UC-09 | ✓ | | |
|
||||
| UC-10 | ✓ | | |
|
||||
@@ -1578,6 +1638,38 @@ layer. Architecture logged for `SHARD-WP-0002` (T11/T14): storage-module abstrac
|
||||
second adapter-contract prior art, engine-maintained Git mirror as attach+write surface,
|
||||
GraphQL introspection for capability discovery + selective projection.
|
||||
|
||||
### federated-wiki mapping
|
||||
|
||||
(⊞ UC-70–UC-72 are placed in the **federation** matrix column — Federated Wiki was first
|
||||
surfaced in `research/260608-federation-concepts/` — but their deepened lineage is the
|
||||
**Federated Wiki deep dive**, `research/260614-federated-wiki-deep-dive/findings.md`.)
|
||||
|
||||
| Federated Wiki mechanism (findings §) | Catalog UC |
|
||||
|---------------------------------------|------------|
|
||||
| Page JSON `{title, story[], journal[]}` over HTTP+CORS; static-file sites (§1, §3) | UC-70 (new) |
|
||||
| Per-page append-only **journal** of semantic actions; story = derived replay; `fork` = provenance entry (§1, §2) | UC-71 (new) |
|
||||
| **Neighborhood** (link/fork-discovered) + **roster** (curated) + chorus of forks (§3, §4) | UC-72 (new) |
|
||||
| **fork** = non-destructive copy with source-site attribution (§2, §4) | UC-26 (enriched) |
|
||||
| Forked journal carries upstream cut-point → carry-forward + re-fork (§2) | UC-28 (enriched) |
|
||||
| **Happenings** = time-bounded collaboration leaving durable forks (§3) | UC-30 (enriched) |
|
||||
| Chorus of co-equal, provenance-linked versions; no canonical (§4) | UC-05 / UC-27 (enriched) |
|
||||
| Story-item (paragraph) write granularity; stable 16-hex item `id` (§1, §5) | links UC-35 |
|
||||
| Journal-replay op-log = third merge model (vs git 3-way, CRDT) (§5, §8) | links UC-36 / UC-64 |
|
||||
|
||||
Note: Federated Wiki is the one studied system whose *core job is shard-wiki's own* — a
|
||||
**union of pages from sovereign sites preserving provenance, assembled non-destructively**.
|
||||
It is therefore prior art not for a *shard* but for three of our **pillars**: the
|
||||
**coordination journal** (its per-page append-only **journal** of semantic actions, with
|
||||
the **story** as a derived replay view, UC-71), **overlay-before-mutation** (its **fork** —
|
||||
own-site-only writes, source-site attribution, UC-26), and **union-without-erasure** (its
|
||||
**neighborhood/roster** membership and **chorus** of provenance-linked forks, UC-72). As a
|
||||
shard it attaches as a **REST/file-store hybrid** (page JSON + CORS, UC-70). **Boundary
|
||||
recorded:** adopt the *model* (journal shape, fork-with-provenance, neighborhood) not the
|
||||
client-only union-assembly locus or slug-as-identity; layer our cross-shard identity (T16)
|
||||
above fedwiki's fork-DAG provenance edges. Architecture logged for `SHARD-WP-0002`
|
||||
(T1–T5, T11, T13, T16): journal-as-coordination-journal, story-item write granularity,
|
||||
journal-replay as a third merge model, fork entries as identity≠placement provenance edges.
|
||||
|
||||
---
|
||||
|
||||
## Open questions
|
||||
@@ -1630,5 +1722,9 @@ GraphQL introspection for capability discovery + selective projection.
|
||||
live from the shard's tree/templates, and how is per-attribute provenance recorded?
|
||||
22. For an **engine-maintained Git mirror** (UC-68), is the mirror or the engine DB the
|
||||
source of truth, and how do we write-by-commit without racing the engine's own sync?
|
||||
23. Should the **coordination journal** (UC-71) adopt fedwiki's exact semantic-action
|
||||
vocabulary (create/add/edit/move/remove/fork) at item granularity, or an abstract op
|
||||
set other shards can also emit — and does a **chorus / no-canonical** union (UC-72)
|
||||
compose with shards that assert a canonical? (Federated Wiki dive §9.)
|
||||
23. How does shard-wiki **honor/surface a shard's path-based access rules** (UC-06) in a
|
||||
projection without re-implementing its ACL engine? (Wiki.js dive §9.)
|
||||
Reference in New Issue
Block a user