Operational landscape
The operational landscape shows who does what in the contributable wiki ecosystem. It combines three dimensions:
- Actors — who builds, configures, contributes, reads, hosts
- Components — translation layer, CMS, auth, publishing, content, plugins
- Resource intensity — build-once investment vs periodic updates vs continuous operational work
This is the combined view that determines what to build into software, what to crowdsource, and what requires ongoing resources (money, people, tooling).
See crosswalker’s operational landscape for the sibling project’s version of this analysis.
The work gradient
Section titled “The work gradient”The gradient runs from emerald (build once, rooted in first principles) through amber (community-maintained, shared effort) to red (ongoing operational work that never ends).
Where cyberbaser’s work items fall
Section titled “Where cyberbaser’s work items fall”The responsibility matrix
Section titled “The responsibility matrix”Who owns what across the contributable wiki ecosystem?
Color key: ● One-time/rare — ● Periodic updates — ● Continuous ops — ● N/A
| Translation layer | CMS / contribution | Auth + identity | Publishing pipeline | Content | Plugin abstraction | |
|---|---|---|---|---|---|---|
| Cyberbaser core team | ● Builds remark/rehype plugins, defines tier system | ● Integrates CMS, builds inline editing | ● Builds OAuth proxy, auth model | ● Configures Astro + Starlight + deploy | ● N/A | ● Tests Obsidian CLI/headless compat |
| Vault owner | ● N/A | ● Configures CMS for their vault | ● Sets up OAuth app, manages trusted contributors | ● Deploys, maintains domain | ● Creates + curates content | ● Chooses which plugins to enable |
| Web contributor (zero-git) | ● N/A | ● Uses CMS to edit pages | ● Signs in via OAuth | ● N/A | ● Writes + corrects content | ● N/A |
| Power contributor (Obsidian+git) | ● N/A | ● N/A | ● N/A (uses git directly) | ● N/A | ● Writes content with full Obsidian affordances | ● Uses plugins locally |
| Hosting provider (Cloudflare, GitHub) | ● N/A | ● N/A | ● Provides OAuth endpoints | ● Serves static files, runs Functions | ● N/A | ● N/A |
| Obsidian (the company) | ● Defines OFM spec | ● N/A | ● N/A | ● N/A | ● N/A | ● Maintains CLI/headless runtime |
| Community | ● Reports edge cases, contributes plugins | ● Contributes CMS templates | ● N/A | ● Contributes themes, plugins | ● Contributes content to vaults | ● Tests plugin compat, files issues |
Key insight: The content creation column (rightmost in spirit) is red for almost everyone — because the content is the whole point. No amount of software eliminates the need to write the wiki. Cyberbaser’s job is to make contribution as frictionless as possible, not to write the content itself.
The five tiers of work
Section titled “The five tiers of work”Tier 1: First-principles software (build once)
Section titled “Tier 1: First-principles software (build once)”Work rooted in the fundamental nature of the problem. Once solved correctly, this rarely changes because the underlying principles don’t change.
| Work item | Why it’s resilient | Related |
|---|---|---|
| Translation layer spec (tier system, round-trip rules) | Obsidian-flavored markdown is stable; the tier definitions are structural | Principles #2 |
| Remark/rehype plugins (wikilinks, callouts, embeds) | unified AST ecosystem is mature; plugin interfaces rarely break | Ecosystem |
| Round-trip correctness test suite | Equivalence rules for markdown are mathematical; fixture corpus is durable | Translation layer |
| Content addressing / permalink scheme | URL stability is a wiki cardinal sin to violate; the scheme is chosen once | Primitives: stable URLs |
Business analogy: R&D. High upfront cost, near-zero marginal cost afterward. This is the technical moat — if cyberbaser’s translation layer is the best, it’s reusable as a library (@cyberbaser/translate).
Tier 2: Platform engineering (build and refine)
Section titled “Tier 2: Platform engineering (build and refine)”Built on first principles but adapts as the ecosystem shifts. Changes on the order of months to years.
| Work item | What causes change | Related |
|---|---|---|
| CMS integration (Decap, Sveltia, EmDash) | CMS landscape evolves; new features, new APIs | Roadmap: CMS survey |
| Auth + OAuth proxy | Auth standards evolve; new providers emerge | Roadmap: auth model |
| Inline editing UX | Editor tech improves (BlockSuite, Tiptap) | Vault vision |
| Publishing pipeline (Astro + Starlight) | Astro/Starlight version updates, new integrations | Architecture |
| Plugin abstraction (Obsidian CLI/headless) | Obsidian’s headless runtime evolves; community plugins adapt | Roadmap: plugin execution |
Business analogy: Product engineering. This is the platform value — the integration work that vault owners don’t want to do themselves. A hosted service (“bring your vault, get a contributable wiki”) is Tier 2 work packaged as a product.
Tier 3: Community-maintained (shared work)
Section titled “Tier 3: Community-maintained (shared work)”Per-vault or per-plugin work that’s shareable. Once someone figures it out, everyone benefits.
| Work item | Who does it | Related |
|---|---|---|
| Plugin compatibility profiles (which Obsidian plugins work in headless mode) | Community tests; cyberbaser validates | Roadmap: plugin execution |
| Vault templates / starter configs | First vault owner configures; shares via template repo | Existing work |
| Contribution guidelines + PR templates | Community refines; vault owner customizes | Contribution workflows |
| Theme variants (beyond silver+emerald) | Community contributes; cyberbaser maintains as examples | Current: brand.css |
Business analogy: Marketplace / ecosystem. The more contributors, the more valuable each contribution. Like Obsidian’s community plugin ecosystem — once someone builds a plugin, thousands of vaults benefit.
Key insight: This is where a community config registry (like crosswalker’s config browser) would create the most value — per-vault configuration done once, shared infinitely.
Tier 4: Operational maintenance (ongoing)
Section titled “Tier 4: Operational maintenance (ongoing)”Work that recurs because the external world changes. Cannot be eliminated — only automated or made more efficient.
| Work item | Why it recurs | Related |
|---|---|---|
| Hosting + deployment | Cloudflare Pages Functions, domain management, SSL | Architecture |
| Dependency updates (Astro, Starlight, CMS, plugins) | Upstream releases on their own schedule; security patches | Development |
| Content moderation (spam, abuse, PR review) | Abuse scales with openness; Open Authoring = open attack surface | Contribution workflows |
| OAuth proxy maintenance | Token handling, secret rotation, provider API changes | Roadmap: auth model |
Business analogy: DevOps / SRE. If cyberbaser were a business, this is where subscription revenue funds ongoing labor. A hosted service wraps Tier 4 into a monthly fee so vault owners don’t have to manage it.
Tier 5: User work (your effort)
Section titled “Tier 5: User work (your effort)”Work specific to YOUR vault. No tool can eliminate it — only make it more efficient.
| Work item | Why only you can do it | Related |
|---|---|---|
| Content creation | Only you know what to write about | The whole point |
| Contribution review | Only you can judge quality and accuracy for your domain | Contribution workflows |
| Vault organization | Only you know the right structure for your knowledge domain | Primitives: vault |
| Contributor management | Only you decide who to trust with auto-merge vs manual review | Contribution workflows |
Business analogy: Customer’s work. Cyberbaser makes contribution FASTER and more reliable, but the actual knowledge is irreducibly human.
The sustainability question
Section titled “The sustainability question”If cyberbaser were a business, where would the money come from?
| Tier | Funding model | What it looks like |
|---|---|---|
| Tier 1 (first-principles software) | Open-source + grants + sponsorship | The translation layer is MIT-licensed. Anyone can use it. Goodwill + ecosystem gravity. |
| Tier 2 (platform engineering) | Hosted service (SaaS) | “Bring your vault, get a contributable wiki.” Monthly fee covers CMS setup, auth, inline editing, deployment. This is the product. |
| Tier 3 (community) | Self-sustaining once critical mass is reached | Plugin compat profiles, vault templates, contribution guidelines — all community-contributed. |
| Tier 4 (operations) | Included in the SaaS fee | Hosting, dependency updates, content moderation tooling, OAuth proxy — vault owners don’t want to manage this. |
| Tier 5 (user work) | The value proposition | Cyberbaser sells efficiency, not elimination. “Your wiki, your content, but anyone can contribute without learning git.” |
The core business thesis: Tier 1 is the technical moat (hard to replicate). Tier 2+4 packaged together is the product (a hosted contributable wiki service). Tier 3 is the ecosystem (community contributions make the platform more valuable). Tier 5 is what the customer actually pays for — making their irreducible work as painless as possible.
Comparison to existing models:
- Obsidian Publish charges $10/month for Tier 2+4 — but has NO contribution model (no Tier 5 efficiency)
- GitBook charges per user for Tier 2+4 — but has NO Obsidian fidelity (no Tier 1 moat)
- Notion public pages is free for read — but has NO git SSOT (violates Principle 1)
- Cyberbaser occupies the intersection: Obsidian fidelity + git SSOT + zero-git contribution + hosted service
What this means for the roadmap
Section titled “What this means for the roadmap”The Research & Foundations roadmap should be read through this lens:
- Identity question → determines which tiers to invest in first
- CMS survey → Tier 2 decision (the platform choice)
- Auth model → Tier 2+4 decision (infrastructure + ongoing maintenance)
- Plugin abstraction → Tier 1 investment (if solved, becomes the technical moat)
- Collaboration model → Tier 2 scope (real-time collab = much more Tier 4 ops work)
- Translation layer → Tier 1 investment (the foundation everything else builds on)
- Operational model → THIS PAGE (which tiers get resourced, in what order)
The architecture goal: Push as much work as possible toward Tier 1 (solved once, resilient). Where that’s impossible (Tiers 3-4), build community infrastructure so the work is shared. Only Tier 5 is irreducibly the user’s burden.
Related
Section titled “Related”- The Problem — what gap cyberbaser fills
- Architecture — technical components mapped to tiers
- Contribution Workflows — who does what to contribute
- Roadmap — what’s being researched in which order
- Vault vision mining — the original dream
- Crosswalker operational landscape — sibling project’s version