feat: add knowledge base foundation pages for SEO

pages/_meta.js

@@ -13,6 +13,10 @@ export default {
     title: "Docs",
     type: "page"
   },
+  kb: {
+    title: "Knowledge Base",
+    type: "page"
+  },
   blog: {
     title: "Blog",
     type: "page"

pages/kb/_meta.js

@@ -0,0 +1,10 @@
+export default {
+  index: {
+    title: "Knowledge Base"
+  },
+  "what-is-crdt": "What Is a CRDT?",
+  "loro-vs-yjs": "Loro vs Yjs",
+  "crdt-library-comparison": "CRDT Library Comparison",
+  "build-collaborative-editor": "Build a Collaborative Editor",
+  "crdt-time-travel": "CRDT Time Travel"
+}

pages/kb/build-collaborative-editor.mdx

@@ -0,0 +1,91 @@
+---
+title: "How to Build a Collaborative Editor with CRDTs"
+description: "Learn the key architecture decisions behind building a collaborative editor, including document model, sync, offline support, conflict resolution, and version history."
+keywords: "build collaborative editor, collaborative text editor architecture, real-time editor crdt, collaborative editing tutorial"
+---
+
+# How to Build a Collaborative Editor with CRDTs
+
+Building a collaborative editor is not just about broadcasting keystrokes. A real product has to survive concurrent edits, reconnect after network loss, preserve document structure, and help users recover from mistakes.
+
+CRDTs are often a strong fit because they let each client update locally and synchronize later while still converging on the same document state.
+
+## What a collaborative editor actually needs
+
+At minimum, you need:
+
+- a document model for the shared content
+- a sync layer to move updates between clients
+- a persistence layer so state survives app restarts and reconnects
+- presence / awareness for cursors, selections, and who is online
+- a history model for undo, restore, and version inspection
+- auth and permissions so not everyone can mutate everything
+
+## Why CRDTs are a good fit
+
+CRDTs help with the core document-state problem:
+
+- multiple users edit concurrently
+- clients may be offline temporarily
+- updates can arrive in different orders
+- all replicas still need to converge
+
+## What CRDTs solve — and what they do not
+
+CRDTs help with shared document state, concurrent merge behavior, offline edits that sync later, and deterministic convergence.
+
+They do **not** automatically solve authentication, authorization, presence, transport infrastructure, or product-specific permission flows.
+
+## The core architecture pieces
+
+A practical collaborative editor usually has these parts:
+
+1. Document model
+2. Local editing state
+3. Sync transport
+4. Persistence
+5. Presence / awareness
+6. Version history
+
+## Text editors vs structured editors
+
+There is a big difference between a shared text buffer and a structured collaborative editor. If the product is trending toward structured content, pick a library that will not fight you later.
+
+## Offline-first and reconnect behavior
+
+A solid collaborative editor should handle:
+
+- local edits while disconnected
+- replaying updates on reconnect
+- merging with remote edits safely
+- reloading large documents without bizarre corruption or duplicate state
+
+## Why version history matters
+
+If you stop at convergence, you get a collaborative system.
+If you add inspectable history and restore points, you start getting a trustworthy product.
+
+## A practical stack with Loro
+
+A simple architecture with Loro might look like this:
+
+- client: editor UI + Loro document in memory
+- transport: WebSocket, WebRTC, or your own sync channel
+- backend: stores snapshots and/or updates, enforces auth and permissions
+- history UX: built on top of Loro's document history / time-travel capabilities
+
+## Common mistakes when building collaborative editors
+
+- treating presence like document state
+- only testing on perfect networks
+- forgetting recovery and versioning
+- choosing a data model that is too shallow
+
+## What to read next
+
+- [Get Started with Loro](/docs/tutorial/get_started)
+- [Learn how sync works](/docs/tutorial/sync)
+- [Explore Time Travel](/docs/tutorial/time_travel)
+- [Understand the CRDT basics](/kb/what-is-crdt)
+- [Loro vs Yjs](/kb/loro-vs-yjs)
+- [CRDT Library Comparison](/kb/crdt-library-comparison)

pages/kb/crdt-library-comparison.mdx

@@ -0,0 +1,92 @@
+---
+title: "CRDT Library Comparison: Loro vs Yjs vs Automerge"
+description: "A practical comparison of CRDT libraries including Loro, Yjs, and Automerge across ecosystem, language support, data models, local-first fit, and collaboration use cases."
+keywords: "crdt library comparison, best crdt library, yjs vs automerge vs loro, javascript crdt library"
+---
+
+# CRDT Library Comparison
+
+There is no single best CRDT library for every product. Real teams choose one for a specific product shape: a collaborative editor, a local-first document app, a structured knowledge tool, or a shared data layer with offline sync.
+
+## Quick answer
+
+Choose **Yjs** if ecosystem safety and editor integration depth matter most.
+
+Choose **Automerge** if you are strongly local-first in philosophy and your use case leans toward general replicated app state.
+
+Choose **Loro** if you want collaboration plus a stronger document history/time-travel story, especially for structured content.
+
+## What to compare when choosing a CRDT library
+
+Useful criteria:
+
+- document model shape
+- ecosystem maturity
+- local-first fit
+- history / versioning story
+- long-term product fit vs fastest adoption
+
+## Comparison overview
+
+### Yjs
+
+Strong JavaScript adoption, collaborative editor mindshare, mature ecosystem.
+
+### Automerge
+
+Strong local-first association and replicated app-state narrative.
+
+### Loro
+
+Richer structured document orientation, stronger emphasis on document history and time travel.
+
+## Comparison table
+
+| Dimension | Loro | Yjs | Automerge |
+| --- | --- | --- | --- |
+| Ecosystem maturity | Growing | Strongest today | Established but more niche in some workflows |
+| JavaScript mindshare | Moderate | Strong | Moderate |
+| Editor ecosystem gravity | Limited vs Yjs | Strongest | Lower than Yjs |
+| Structured document fit | Strong | Good | Good |
+| History / time-travel emphasis | Strong | Varies by surrounding architecture | Strong local-first narrative |
+
+**TODO:** Replace directional wording with tighter, citation-backed capability statements where official docs give enough evidence.
+
+## Best for JavaScript-first teams
+
+Yjs has the clearest advantage today if you want the most familiar collaboration ecosystem.
+
+## Best for local-first products
+
+All three libraries can participate in local-first architectures, but they support different product stories.
+
+## Best for document history and time travel
+
+This is where Loro stands out most clearly.
+
+## Best for editor integrations
+
+If your main question is which library gives the broadest editor-oriented ecosystem and least surprising integration path, Yjs is usually the strongest answer.
+
+## Where Loro is differentiated
+
+Loro becomes more compelling when:
+
+- the document is highly structured
+- tree-like or movable content matters
+- version history is user-facing
+- collaboration and restore/replay belong in the same product story
+
+## Common mistakes when choosing a CRDT library
+
+- picking on popularity alone
+- over-focusing on toy benchmarks
+- ignoring history until later
+- treating all collaborative apps as text editors
+
+## What to read next
+
+- [What Is a CRDT?](/kb/what-is-crdt)
+- [Loro vs Yjs](/kb/loro-vs-yjs)
+- [How to Build a Collaborative Editor](/kb/build-collaborative-editor)
+- [Get Started with Loro](/docs/tutorial/get_started)

pages/kb/crdt-time-travel.mdx

@@ -0,0 +1,64 @@
+---
+title: "CRDT Time Travel: Version History for Local-First and Collaborative Apps"
+description: "See how CRDT time travel enables version history, undoable exploration, and Git-like document inspection in collaborative and local-first applications."
+keywords: "crdt time travel, document version history crdt, local-first version control, collaborative editing history"
+---
+
+# CRDT Time Travel
+
+Most collaboration content focuses on one thing: how multiple replicas converge. But real products also need to answer what changed, whether users can restore an older version, and how a document evolved over time.
+
+In a CRDT system, time travel means you can work with more than just the latest state. You can inspect history, reconstruct earlier versions, and build product features around document evolution.
+
+## What does “time travel” mean in a CRDT system?
+
+Time travel usually means some combination of:
+
+- viewing earlier document states
+- restoring a previous version
+- replaying changes over time
+- inspecting how a document evolved
+- building history-aware product features on top of synchronized state
+
+## Why version history matters in collaborative apps
+
+Version history helps with:
+
+- recovery
+- trust
+- review and inspection
+- product differentiation
+
+## Why this is hard to bolt on later
+
+Once persistence model, sync flow, and product assumptions revolve around only the latest state, adding high-quality version history becomes much more painful.
+
+## CRDT time travel vs undo/redo
+
+Undo is often local and session-oriented.
+Time travel is about durable document history.
+
+## Product features enabled by time travel
+
+- version history views
+- restore flows
+- replay / change walkthroughs
+- snapshot-based workflows
+- trust-building UX
+
+## How Loro fits here
+
+Loro is not only positioned as a CRDT library for convergence. It also has a stronger story around document history and time travel.
+
+**TODO:** Align exact terminology and capability wording with Loro’s official time-travel docs so the page stays precise instead of vague.
+
+## When you should care about this feature
+
+Care early if your product needs restore, review, recoverability, or structured content history as part of the UX.
+
+## What to read next
+
+- [Time Travel Tutorial](/docs/tutorial/time_travel)
+- [Learn how sync works](/docs/tutorial/sync)
+- [Loro vs Yjs](/kb/loro-vs-yjs)
+- [How to Build a Collaborative Editor](/kb/build-collaborative-editor)

pages/kb/index.mdx

@@ -0,0 +1,46 @@
+---
+title: "Loro Knowledge Base"
+description: "Search-first guides for CRDTs, collaborative editing, local-first architecture, and evaluating Loro against other CRDT libraries."
+keywords: "loro knowledge base, crdt guides, collaborative editing, local-first, yjs alternative"
+---
+
+import { Cards } from "nextra/components";
+
+# Loro Knowledge Base
+
+Search-first guides for engineers evaluating CRDTs, collaborative editing architecture, and local-first software.
+
+Use this section when you want the big picture first:
+- what CRDTs are
+- how to compare Loro with Yjs and Automerge
+- how to design a collaborative editor
+- why document history and time travel matter
+
+## Start here
+
+<Cards num={2}>
+  <Cards.Card arrow title="What Is a CRDT?" href="/kb/what-is-crdt">
+    Learn the core idea behind conflict-free replicated data types and why they matter for offline and real-time apps.
+  </Cards.Card>
+  <Cards.Card arrow title="Loro vs Yjs" href="/kb/loro-vs-yjs">
+    A practical comparison for teams choosing a CRDT library for collaborative software.
+  </Cards.Card>
+  <Cards.Card arrow title="CRDT Library Comparison" href="/kb/crdt-library-comparison">
+    Compare Loro, Yjs, and Automerge across ecosystem, data model, and product fit.
+  </Cards.Card>
+  <Cards.Card arrow title="How to Build a Collaborative Editor" href="/kb/build-collaborative-editor">
+    A search-first architecture guide for collaborative text and document products.
+  </Cards.Card>
+  <Cards.Card arrow title="CRDT Time Travel" href="/kb/crdt-time-travel">
+    Understand document history, replay, and versioning in local-first and collaborative apps.
+  </Cards.Card>
+</Cards>
+
+## Looking for implementation details?
+
+If you already know what you want to build and just need APIs and examples, go straight to the docs:
+
+- [Get Started](/docs/tutorial/get_started)
+- [CRDT Concepts](/docs/concepts/crdt)
+- [Sync Tutorial](/docs/tutorial/sync)
+- [Time Travel Tutorial](/docs/tutorial/time_travel)