The lighter revibe of Federated Wiki is a **new single page application** that reimplements the original Fedwiki client in a web component style, without pulling in a big framework like React.
It talks to the **same JSON endpoints** and uses the **same on disk page format** as the classic client, but swaps the old jQuery era scripts for a modern, modular SPA built from custom elements and a tiny block model. The old Fedwiki server can stay exactly as it is, or be gradually reimplemented behind the same HTTP and JSON contract.
# New SPA, Same JSON Contract The revibed client is its own SPA, served as a bundle of HTML, JS and CSS that boots into a root custom element such as `<fw-app>`. On startup it: - Discovers or is configured with one or more Fedwiki servers. - Fetches page JSON via the existing `page` and `status` endpoints. - Renders lineups and neighbourhoods in the familiar card based layout. When the user edits and saves, the SPA sends updated `{ title, story, journal }` back to the same endpoints the original client uses. From the server’s perspective it is just another Fedwiki client, speaking the same JSON dialect as before.
# Web Components As Building Blocks Instead of a single monolithic script file, the lighter revibe organises the client into a small set of web components. Examples might include: - `<fw-app>` for overall app lifecycle and routing. - `<fw-lineup>` for the row of pages. - `<fw-page-card>` for each individual page card. - `<fw-page-editor>` for editing the current page. - `<fw-block>` and specialised `<fw-paragraph-block>`, `<fw-image-block>`, `<fw-plugin-block>` for story items. Each custom element owns its own markup, styles and behaviour, relying only on browser APIs and a small shared state module.
# Tiny Block Model Aligned With Story[] At the heart of the new SPA is a **small block model** that maps directly to the Fedwiki `story[]` array. Each page in memory looks like: - `title` as a string. - `blocks` as an array, where each block has `id`, `type` and `data`. - `journal` as an array of actions, mirroring the existing journal semantics. The valid `type` values are chosen to match existing Fedwiki item types as closely as possible such as `paragraph`, `markdown`, `image`, `factory`, `plugin`. When the SPA loads a page it transforms `story[]` into `blocks`. When it saves, it transforms `blocks` back into `story[]` with no extra fields that would confuse classic clients.
# Page Editing In The SPA Editing happens entirely inside the new SPA, not as a single embedded widget in the old client. The `<fw-page-editor>` element: - Receives a page model `{ title, blocks, journal }`. - Instantiates a `<fw-block>` element for each block in order. - Uses `contenteditable` and small controls (handles, menus) to support editing, splitting and reordering. Key behaviours are simple and explicit. - Enter splits a paragraph block and creates a new block with a new `id`. - Backspace at the start of a block merges upwards when possible. - Dragging a handle moves a block in the array. The editor shell keeps the in memory page model updated and is the only place that knows about the correspondence between block operations and journal entries.
# Plugins As First Class Blocks Plugins are modelled as blocks of `type: "plugin"` with their original Fedwiki plugin JSON stored in `data`. A `<fw-plugin-block>` element: - Renders a minimal configuration view for editing plugin parameters. - Optionally mounts the classic plugin rendering logic inside a shadow DOM or iframe for live previews. On save the SPA writes back the plugin block as a `story[]` item identical to the original plugin representation so that existing plugin code on the server side continues to work. This keeps the plugin ecosystem intact while giving editors a more coherent block based UI.
# Routing, Lineups And Neighbourhoods The lighter revibe does not change the core Fedwiki navigation patterns. The SPA’s router understands page slugs, site origins and the multi card layout, and renders them as a `<fw-lineup>` of `<fw-page-card>` elements. Neighbourhood discovery, recent changes and forking remain driven by the same JSON structures and URL patterns as the old client, just presented through web components instead of jQuery. This means existing habits like dragging cards, forking pages and following provenance still feel like Fedwiki, only smoother.
# Agent And Amp Friendly Design Because the new SPA speaks the same JSON as the original client, it is naturally compatible with Sourcegraph Amp and other agents. Amp can be pointed at the Fedwiki server or at a local farm directory and treat pages as structured JSON files, independent of how the SPA renders them. The small block model makes it easy for agents to propose edits at the block level rather than injecting raw HTML. In future the SPA can expose an optional HTTP or MCP style interface for local tools to manipulate open pages directly, but none of that is required for basic compatibility.
# Migration And Coexistence The new SPA can coexist with the original Fedwiki client. A Fedwiki server can serve both `client/old` and `client/new`, letting users opt in to the revibed experience while keeping the legacy UI available. Because both clients read and write the same JSON files, there is no migration window or format split. Over time administrators can switch the default client to the web component SPA, confident that federation and compatibility remain intact.