Skip to content
Cyberbaser
🧠 Research & Foundations phase — building the KB from the ground up. See the roadmap →

Roadmap

Updated

Cyberbaser is the contributable wiki platform — Obsidian authoring, GitHub as the single source of truth, zero-git contribution for anyone. The roadmap reflects this: research and architecture come first, features are built on that foundation, and every significant decision is logged with rationale.

See the vault vision mining for the original dream, and the vault tech stack mining for the 300+ curated links that seed the research below.

Current phase: Research & Foundations

Section titled “Current phase: Research & Foundations”

Research & Foundations — “Know what we’re building before we build it”

Section titled “Research & Foundations — “Know what we’re building before we build it””

The vault research shows ambitions spanning publishing, contribution, and real-time collaboration — but the project identity, CMS choice, auth model, and collaboration strategy are all still open. This phase resolves them before code.

Research & spec (iterative, first-principled):

  • Cyberbaser identity — is this a publishing tool, a wiki platform, a collaboration framework, or all three? The vault vision is more ambitious than the current docs describe (includes live anonymous collab, contributor attribution, plugin execution across environments). Need to decide what’s v1 vs what’s deferred. Shapes every downstream decision.
  • CMS landscape survey — the vault has 20+ CMS options evaluated at varying depths. Need to narrow to 2-3 finalists: Decap (Open Authoring), Sveltia, Tina, EmDash (Cloudflare-built, Astro-native, AI-agent-first — announcement), Pages CMS, and others from RESEARCH_SOURCES. The CMS IS the zero-git contribution path — wrong choice = wrong contribution UX.
  • Auth model — GitHub OAuth only, or multi-provider? The vault has 20+ auth solutions researched (Better-Auth, Clerk, Ory/Kratos, SuperTokens, Authentik with Wiki.js integration, and more). Auth gates the contribution path — scope decision for v1.
  • Plugin execution abstraction — how can Obsidian community plugins (Dataview, linting, attachment management) run outside the desktop app? This was the “hardest layer” identified in the vault vision. Major update: Obsidian now has an official headless runtime + CLI tool (ships with 1.12, Early Access). If community plugins load in headless/CLI mode, this problem may already be solved. Needs hands-on testing. obsidianless enables headless Linux servers. HN discussion.
  • Collaboration model — git-only async, or real-time live editing? The vault vision includes “edit with someone → anonymous secure live editing.” The vault survey found 4 models (file-level P2P, live collab via Peerdraft/LiveSync, git-based, workaround methods). 50+ CRDT/sync links from vault tech stack mining (Yjs, Automerge, BlockSuite, ElectricSQL). Preliminary recommendation: defer real-time to v2, focus v1 on the three async paths.
  • Translation layer deep-dive — does astro-loader-obsidian handle Tier 1 features (wikilinks, callouts, embeds, math, Mermaid) sufficiently, or do we need custom remark/rehype plugins? Changes Phase 1 scope by 5-10x. Requires hands-on testing with real cyberbase vault content against the Obsidian Flavored Markdown spec. Also evaluate Markdoc as an alternative authoring format. starlight-theme-obsidian is worth examining.
  • Publish site survey — review 10-15 of the 60+ example Obsidian Publish sites catalogued in the vault (the local research vault). Extract UX patterns: navigation, search, mobile, backlinks, graph view, contributor attribution, SEO. The reader experience determines whether people actually use the wiki.
  • Data sync strategy — how does content flow between Obsidian (local) → GitHub (repo) → Web CMS (edits) → built site? The vault identified specific failure modes: Obsidian Git conflicts from date-modified fields, Windows path length limits, bracket escaping in filenames. Media hosting at scale (Cloudinary + S3/Storj per the vault tech stack). Resumable uploads via tus.io. Architecture: current diagram.
  • SEO baseline — sitemaps, robots.txt, canonical URLs, OG images, structured data. Which does Starlight handle, which need custom work? The vault has research in the local research vault. Stable URLs on Obsidian Publish is the key reference for permalink design (R08 / content addressability).
  • Operational model + sustainability — where does the sustained work live in cyberbaser? Which layer creates enough value that someone would pay to not build/maintain it? Candidate value centers: translation layer as a library (@cyberbaser/translate), contribution widget (SaaS-able “add contributability to any Obsidian site”), plugin execution in CI/headless (unique capability), hosted service (“bring your vault, get a contributable wiki”), enterprise tier (RBAC, audit, teams). See crosswalker’s operational landscape for the pattern. Informs license choice and what to protect vs. give away. Intertwined with identity — “what is cyberbaser” and “what’s the business” answer together.
  • Inline editing UX — what does “click edit on any page and immediately edit the content right there” actually mean technically? Decap widget, TinaCMS inline mode, EmDash’s AI-agent-first portable text, custom BlockSuite/Tiptap editor, Prose (GitHub content editor), or something else? This is the dream feature that closes the reader→contributor loop. Synthesizes CMS choice, auth model, and translation layer decisions.

Infrastructure:

  • Bug fixes and polish on current docs site (Starlight + Nova + silver/emerald theme)
  • Expand Playwright smoke tests for new research pages
  • Update .claude/ numbered files to reflect decisions as they’re made

Exit criteria — all must be true before Research & Foundations closes:

  • Identity stated in one sentence in Problem
  • CMS shortlist narrowed to 2-3 with a recommended pick and rationale
  • Auth model chosen with v1 scope boundaries
  • Plugin abstraction tested (Obsidian CLI + community plugins) and scoped (v1 or deferred)
  • Collab model decided: git-only for v1 or real-time with evidence
  • Translation layer evaluated against Tier 1 feature list with real vault content
  • 10+ Publish sites reviewed with extracted patterns
  • Data sync architecture documented with failure modes
  • SEO checklist completed (Starlight-handles vs custom-needed)
  • Inline editing UX chosen with reference implementation or mockup

Publishing prototype Parked

Section titled “Publishing prototype Parked”

What exists from before the reinit (see Existing Work):

  • Astro + Starlight scaffold with Nova theme, full plugin stack
  • 57 pages of first-principles content + vault mining logs
  • Playwright smoke tests (32 passing)
  • Cloudflare Pages deploy workflow
  • Custom inline SVG diagrams, silver+emerald theme, rotating hero
  • Cross-platform preflight script for WSL/Windows

Resumes after Research & Foundations with possible rewrites based on findings.

Future phases Deferred

Section titled “Future phases Deferred”

Translation layer spike

Section titled “Translation layer spike”

Prove Tier 1 translation with real vault content. Depends on the translation layer deep-dive above.

Contribution workflows

Section titled “Contribution workflows”

Implement CMS + auth + inline editing. Depends on CMS survey, auth model, and inline editing UX above.

Publish the real vault

Section titled “Publish the real vault”

Point at cybersader/cyberbase and deploy to a real domain. Depends on data sync strategy and SEO baseline above.

Community onboarding

Section titled “Community onboarding”

CONTRIBUTING.md, docs, examples, first external contributor.

Operating rules

Section titled “Operating rules”
Research = logged decision
Every research task links to a dated entry in Agent context · zz-log. No research done off the books.
Roadmap is downstream of research
Don’t add implementation steps to later phases until the relevant research task is resolved.
Phase exits only by the exit criteria
No “close enough” shortcuts.