Revibing Federated Wiki using BlockNote and Sourcegraph Amp is about giving Fedwiki a new editing vibe without breaking its JSON based file format or its small pieces, loosely joined philosophy.
Instead of forking Fedwiki into something unrecognisable, the goal is to use agentic coding with Sourcegraph Amp to reverse engineer the existing codebase and wrap it with a modern block based editor, while preserving on disk `story[]` and `journal[]` compatibility.
# Motivation Classic Fedwiki got a lot right early: JSON pages, neighbourhoods, forking, provenance and a plugin system.
What it did not fully keep up with is the modern feel of editing and the way tools and agents want to consume structured content rather than ad hoc HTML.
Using BlockNote for editing and Sourcegraph Amp for vibe coding gives us a way to evolve the UX and internal adapters while respecting the original JSON contract for pages.
# Roles In this revibe there are three primary roles. Federated Wiki remains the canonical page store and federation engine, still serving and saving JSON files in the classic layout. BlockNote becomes the block based page editor, turning each `story[]` item into a rich, typed block tree while exposing a fluid Notion like UI. Sourcegraph Amp acts as the vibe coding framework, reading the Fedwiki codebase, planning changes and generating adapters that map between BlockNote’s block documents and Fedwiki’s file based JSON format.
# Reverse Engineering Fedwiki With Amp Sourcegraph Amp is pointed at a local clone of the Fedwiki server and plugin repos, with full access to the existing page loading, saving and rendering code paths. The first job is to have Amp identify all the places where `story[]` and `journal[]` are read, mutated and written, and to trace how different item types are rendered into HTML. From this, Amp can generate a schema description that says “for each story item type, here is its JSON shape, its HTML representation and any plugin responsibilities”. That schema becomes the contract that any BlockNote integration must honour if we want old pages to keep working and new pages to remain forwards and backwards compatible.
# Maintaining JSON File Compatibility A hard constraint of the revibe is that Fedwiki’s on disk format stays recognisably the same. Pages are still JSON files with `title`, `story[]`, `journal[]` and any extra fields that plugins expect, stored in a flat file hierarchy or simple farm layout. When a page is edited through BlockNote, the result is not a new format but a transformed `story[]` array that fits the existing item types, or clearly versioned extensions of them. Amp generated adapters are responsible for translating between BlockNote’s internal block tree and the old style JSON items so that existing servers, farms and plugins do not break.
# BlockNote As The Page Editor Within the browser, Fedwiki loads a BlockNote based editor instead of the classic textarea plus inline plugin UI.
Each story item is deserialised into one or more BlockNote blocks, capturing headings, paragraphs, images, code and embeds with explicit types and metadata.
When the user edits and saves, BlockNote’s block document is passed through an Amp generated mapping layer that emits a clean `story[]` array mirroring the original page structure. This lets editors get a modern block based experience while the underlying JSON remains boring and predictable.
# Vibe Coding Workflow With Amp Vibe coding means treating Amp as a collaborative engineer sitting inside the codebase rather than as a one off code generator.
For Fedwiki revibing, the workflow looks like: - Point Amp at the Fedwiki repos and ask it to explain the page lifecycle in terms of functions, modules and data structures. - Have Amp sketch a BlockNote integration plan that explicitly lists which files to modify and which to wrap rather than rewrite. - Let Amp generate the first pass of adapter modules, React components and tests, but keep all changes as small, reviewable Git commits. - Iterate conversationally, asking Amp to refine mappings, preserve more edge cases and keep JSON diffs minimal. The result is a series of small, well scoped changes instead of a giant, risky rewrite.
# Yam Back Matter And Block Metadata To support stable paragraph ids and fine grained metadata the revibe pairs BlockNote with Yam Back Matter. Amp helps weave a thin layer that reflects BlockNote block ids and annotations into a compact Yam style section at the end of the page JSON or Markdown like content. This keeps ids, backlinks and agent annotations out of the visible text while keeping them easy to parse and transform. Because Amp understands both the code and the data, it can ensure that this back matter always round trips cleanly when pages are edited, forked or merged.
# Agents And Local-First Neighbourhoods Once Fedwiki is block aware and JSON compatible, other agents can join the neighbourhood. Sourcegraph Amp can be configured with MCP style tools that let it fetch, diff and patch wiki pages over HTTP or from a local farm directory. Other local agents can subscribe to page changes, run analyses or generate summaries, all without breaking compatibility with classic Fedwiki servers. The federation layer remains simple JSON and HTTP, while the agent ecosystem becomes richer and more automated around it.
# Migration Strategy Amp is also used to design and implement a gentle migration path. Existing pages continue to load as they always have, with the classic HTML viewer rendering `story[]` items for readers who do not opt into the new editor. When a page is opened in the BlockNote editor, Amp backed adapters upgrade the content into a block document, adding ids and minimal Yam metadata as needed. On save, the page is written back as standard JSON, with any new fields added in a backwards compatible way so that old Fedwiki installations still see meaningful content.
# Risks And Guardrails Using Sourcegraph Amp to revibe Fedwiki introduces new power and new risks. Amp could easily propose large refactors or intrusive changes that violate the JSON compatibility guarantee, so guardrails are essential. Every change Amp makes should be constrained by tests that load legacy pages, exercise plugins and compare JSON structures before and after edits. The vibe coding ethos is to keep humans firmly in the loop, using Amp to explore and implement changes but always reviewing diffs through the lens of “does this still look like Fedwiki”.
# See - Federated Wiki - BlockNote - Sourcegraph Amp - Yam Back Matter