The Ecosystem
The four layers
Section titled “The four layers”Cyberbaser’s job composes four distinct concerns. The ecosystem has tools for each layer; the question is which combinations actually work end-to-end.
01 · Publishing / SSG
Section titled “01 · Publishing / SSG”Astro (current choice)
Section titled “Astro (current choice)”General-purpose modern SSG with MDX support, islands architecture, and an excellent ecosystem. Flexible enough to swap layout and theme without rewriting content. The current cyberbaser prototype uses Astro + Starlight.
Why we started here: MDX gives rich interactive content without a heavyweight framework, and Astro’s content collections handle large docs sites gracefully. Weakness: build-time only by default — incremental builds for large vaults need more work.
Starlight (on top of Astro)
Section titled “Starlight (on top of Astro)”Docs-specific Starlight layer that gives you sidebars, autogenerated navigation, search (Pagefind), and sane defaults. Both sibling projects (crosswalker, cyberchaste) use Starlight with the Nova theme.
Quartz v4
Section titled “Quartz v4”The current community baseline for “Obsidian vault → static site.” Quartz is Obsidian-aware out of the box — wikilinks resolve, callouts render, backlinks and graph view both work. Weakness: no contribution model. Quartz is a one-way publisher.
Docusaurus
Section titled “Docusaurus”Facebook’s docs-site incumbent. Excellent navigation, search, versioning. Weakness: opinionated content shape. Not Obsidian-aware; forcing Obsidian content through Docusaurus flattens a lot of the affordances.
MkDocs + Material
Section titled “MkDocs + Material”Python-based, very polished reader UX. Common DIY stack in the cybersecurity community. Weakness: Obsidian integration is plugin-based and brittle; contribution is git-only.
Logseq Publish
Section titled “Logseq Publish”Parallel ecosystem (Logseq is Obsidian-adjacent outliner). Worth understanding because some concepts transfer.
02 · Obsidian translation
Section titled “02 · Obsidian translation”unified / remark / rehype
Section titled “unified / remark / rehype”The AST ecosystem for markdown. Everything else is built on this. Any serious translation layer will use remark (markdown AST) and rehype (HTML AST) plugins composed in a pipeline.
remark-wiki-link
Section titled “remark-wiki-link”Handles [[wikilink]] and [[wikilink|alias]] syntax. Resolvable to custom link formats. Dependency of the current prototype.
remark-obsidian-callout
Section titled “remark-obsidian-callout”Converts Obsidian’s > [!note] callouts to Starlight-compatible aside components. Used by both sibling projects.
astro-loader-obsidian
Section titled “astro-loader-obsidian”Astro content loader specifically for Obsidian vaults. Currently a dep in cyberbaser’s prototype. Unknown whether it’s sufficient — needs evaluation against the Tier 1 feature list in Translation Layer.
Pandoc
Section titled “Pandoc”Heavyweight alternative for full-fidelity markdown transforms. Worth knowing about as a fallback even if not used directly.
03 · Contribution / CMS
Section titled “03 · Contribution / CMS”Decap CMS (formerly Netlify CMS)
Section titled “Decap CMS (formerly Netlify CMS)”Git-backed CMS with an Open Authoring mode where anonymous users can submit PRs via their own GitHub fork. This is the killer feature that makes zero-git contribution possible. Mature but the project has had ownership turbulence; actively maintained as of 2026.
Sveltia CMS
Section titled “Sveltia CMS”Modern fork of Decap built on Svelte. Same Open Authoring concept, better UX, actively developed. Worth evaluating as a Decap replacement.
TinaCMS
Section titled “TinaCMS”Different model — inline visual editing with live preview. Less git-native than Decap; more vendor-aligned. Worth understanding but probably not a fit for the SSOT principle.
GitHub web editor + PR workflow
Section titled “GitHub web editor + PR workflow”The floor. Every GitHub repo already supports “Edit this file” in the web UI. Combined with a well-placed link in the page footer, this gives developer-tier contributors a workable path with zero setup. Awesome-list repos have proven this works at scale.
04 · Hosting + auth
Section titled “04 · Hosting + auth”Cloudflare Pages (current choice)
Section titled “Cloudflare Pages (current choice)”Free tier is generous. Global CDN. Pages Functions can host the OAuth proxy for Decap. Why we picked it: matches sibling projects and handles the OAuth proxy layer.
GitHub Pages
Section titled “GitHub Pages”The zero-config baseline. Both sibling projects use GitHub Pages under a subpath (cybersader.github.io/crosswalker). Works fine for static sites but no Functions layer for OAuth — would require hosting the OAuth proxy separately.
Vercel / Netlify
Section titled “Vercel / Netlify”Commercial alternatives with polished preview deployments. Not chosen because Cloudflare Pages + Functions covers the use case for free.
GitHub OAuth
Section titled “GitHub OAuth”The primary auth mechanism for Open Authoring. Contributors sign in with their existing GitHub account; no new accounts to create. The OAuth proxy (a tiny serverless function) handles the redirect dance between Decap and GitHub’s OAuth endpoint.
The gap this ecosystem doesn’t fill
Section titled “The gap this ecosystem doesn’t fill”The hypothesisThe combination of Starlight (SSG) + a competent translation layer (remark/rehype) + Decap CMS with Open Authoring + Cloudflare Pages + GitHub OAuth should satisfy all three corners of the Problem triangle. No single existing tool does, but the composition might.The open question is whether the translation layer can guarantee round-trip fidelity in practice. Everything else is integration work. The translation layer is where the project either works or doesn’t.
This is why Translation Layer is its own numbered file and the single most load-bearing piece of design work.