09 · Source of truth alternatives

The assignment

Cyberbaser’s Principle 1 states: “GitHub is the single source of truth.” But GitHub is made for CODE, not for content/wiki/knowledge-base workflows. Your job: stress-test this assumption from first principles. Is git actually the right SSOT for a contributable wiki? What else exists? What are the real tradeoffs?

This is not an exercise in replacing GitHub for the sake of it — it’s an honest evaluation of whether the current architecture is built on the right foundation, or if the project is fighting against git’s design assumptions.

The fundamental tension

Git assumes:

• Line-by-line diffs (designed for code syntax)
• Merge conflicts are normal (require developer intervention)
• Branching is cheap (feature branches are the norm)
• History is append-only (rewrites are discouraged)
• Text files are primary; binary/media are second-class

Wiki/content workflows assume:

• Paragraph-level changes (semantic units, not lines)
• Conflicts should be rare and auto-resolvable
• Single trunk preferred (rolling content, not feature releases)
• History is for audit, not branching
• Media is first-class (images, diagrams, attachments)

Key question: where do these conflict for cyberbaser specifically, and is the conflict fatal or manageable?

Sources on the tension: Docs-as-code: broken promise · When docs-as-code reaches its limits · Martin Fowler: semantic conflict

What to investigate

1. Git forges beyond GitHub

Not all git forges are equal. Evaluate for cyberbaser’s specific needs (Open Authoring, OAuth, contributor UX):

• GitLab (self-hosted, stronger CI) — heavy footprint but powerful
• Forgejo (community-governed Gitea fork) — lightweight, single binary, powers Codeberg
• Codeberg — non-profit hosted Forgejo. No corporate control.
• Radicle — P2P decentralized git. No central SSOT at all.
• SourceHut — email-driven workflows. Excludes non-technical contributors entirely.

Question: if cyberbaser wants self-hosting capability, is Forgejo + Decap CMS a better foundation than GitHub + Decap?

2. Non-git version control designed for content

• Fossil — SQLite-based VCS with built-in wiki, bug tracker, forum. Wiki is first-class. Used by SQLite itself. Fossil vs Git
• Pijul — patch-based VCS with mathematically sound merges (patches commute). Better for content than git’s snapshot model?
• Jujutsu (jj) — git-compatible but with better UX (no staging area, implicit commits, better undo). Could sit on top of git transparently.

Question: would Fossil’s wiki-first design serve cyberbaser better than git’s code-first design? The tradeoff: losing Obsidian authoring integration and the entire GitHub ecosystem.

3. CRDT-native content systems

These store content as conflict-free replicated data types instead of files-in-git:

• Yjs — shared data types for real-time collab. Powers Tiptap, BlockSuite, ProseMirror. GitHub
• Automerge — JSON-like CRDT with rich history. Automerge 2.0
• OctoBase — from AFFiNE. CRDT database, local-first, P2P-capable. GitHub
• BlockSuite — CRDT-native content editing framework from AFFiNE. CRDT-native data flow
• Loro — high-performance CRDT with Peritext (rich text) support. Newer competitor to Yjs.
• Jazz — CoJSON collaborative framework with built-in permissions, roles, and sync.

Question: could a vault be represented as a CRDT document set instead of files-in-git? What’s gained (real-time collab, auto-merge) and what’s lost (git audit trail, Obsidian compatibility, file portability)?

4. Local-first databases

• ElectricSQL — Postgres ↔ SQLite sync. CRDT-based merging.
• PowerSync — Postgres → SQLite sync with fine-grained rules.
• RxDB — reactive offline-first NoSQL with CouchDB-compatible replication.
• Turso — SQLite at the edge with distributed replicas.
• Evolu — local-first SQLite + CRDT sync, privacy-first.
• Triplit — full-stack database with real-time sync and CRDT conflict resolution.

Question: these all solve sync beautifully but none have branching/PR/approval semantics. Is automatic conflict resolution actually what cyberbaser wants, or does human review (git’s model) better serve a wiki where accuracy matters?

5. Decentralized / P2P content systems

• IPFS — content-addressed, distributed, immutable. Cloudflare IPFS gateway. No native versioning.
• Hypercore/Pears — P2P append-only logs. Real-time data sharing.
• Solid — Tim Berners-Lee’s data pods with user sovereignty. Project Liberty integration
• AT Protocol — Bluesky’s federated data model with portable identity.
• Nostr — decentralized event protocol. Censorship-resistant. State of Nostr 2025
• Ceramic — decentralized data network with mutable documents on IPFS.

Question: could a vault live on a personal data server (Solid pod, AT Protocol PDS) instead of GitHub? What’s the contribution model look like? Is decentralization a feature cyberbaser’s users actually want?

6. What real-world wikis actually use

System	Storage	Sync	Real-time?	Contribution model
Wikipedia/MediaWiki	MySQL, delta compression	Async	No	Open with gatekeeping
Notion	PostgreSQL, sharded	WebSocket + CRDT	Yes	SaaS, real-time
Obsidian Publish	Files + encrypted cloud	Async	No	Read-only
GitBook	GitHub + secondary DB	Async, bidirectional	No	Visual editor + PRs
Outline	PostgreSQL	WebSocket	Yes	Permissioned teams
AFFiNE	OctoBase (CRDT)	CRDT sync	Yes	Local-first + cloud
Wiki.js	PostgreSQL, MySQL, or git	Various	Partial	Web editor
BookStack	MySQL	None	No	Role-based web editor
DokuWiki	Flat files (no DB)	None	No	Web editor

Question: which of these architectures is closest to what cyberbaser needs? Is there a successful wiki that uses git as primary SSOT with non-technical contribution?

7. Federation, mixed-privacy, and role-based access

A deeper vision question that stresses every filesystem-based SSOT: the long-term vision includes federated KBs and partly-public/partly-private/role-based vaults. Imagine:

• A network of cyberbaser-powered KBs that can link, embed, or query each other (cross-KB wikilinks, shared taxonomies, federated search)
• A single vault that’s partly public (readable by anyone) and partly private (gated by role, team, or auth)
• Role-based contribution (domain experts can edit their section; everyone can read)

Git + flat files struggles here:

• Git has no native permission model below “push access” — you either own the repo or you don’t
• Cross-repo references are string paths; nothing enforces link integrity across KB boundaries
• Federation needs shared identity (OAuth, DIDs, or pod-based) that doesn’t live in git

Systems that handle this better:

• Jazz has built-in roles and permissions on CRDT data
• Solid pods have fine-grained access control via WebID + WAC
• AT Protocol has portable identity and federation primitives
• Outline + Wiki.js have role-based access built in (at the cost of a database SSOT)

Federation is a protocol problem, not a UI problem. The connection model for federated KBs isn’t “better search bar” — it’s DNS-style discovery: a KB needs to find, resolve, and reference content in another KB across a federated namespace. Crawl + resolve, not manual cross-linking. Relevant protocols to investigate:

• ActivityPub — the Fediverse standard (Mastodon, PeerTube). Federation primitives for actors, objects, activities.
• WebFinger — identity resolution protocol (acct:user@domain → metadata). Works alongside ActivityPub.
• AT Protocol federation — Bluesky’s approach with Personal Data Servers and relays.
• Matrix — federated messaging with decentralized rooms, reputable for real-time + state sync.
• Nostr relays — pub/sub event federation; user-owned keys.
• IPNS — mutable names over IPFS content addressing.
• DIDs (Decentralized Identifiers) — portable cross-system identity (W3C standard).
• IndieWeb: Webmention, Micropub — small, composable protocols for cross-site mentions + posting.
• Federated Wiki (Ward Cunningham) — the original wiki creator’s federated design. Drag pages between sites; fork semantics across instances.
• Bonfire — federated social/knowledge platform built on extensible protocols.
• Fedora Commons — federated repositories for scholarly/cultural KBs.

Questions:

• If cyberbaser’s v2+ vision is federation + mixed-privacy, does that force the SSOT choice NOW, or is “v1 git-only → v2 wrap with federation layer” a viable path?
• Which of the above protocols has the right primitives for a KB (durable content, versioning, transclusion, attribution) vs. a social feed (ephemeral posts)?
• Federated Wiki is the closest prior art — what did Ward Cunningham get right, and why didn’t it win? Is its “fork across sites” model something cyberbaser should adopt?
• Has anyone successfully retrofitted federation onto git-backed content (or proven it can’t be done cleanly)?

8. The hybrid architecture question

The emerging pattern (2025-2026): CRDT for collaboration, git for persistence/audit.

[Real-time editing layer]     (Yjs/Automerge/BlockSuite)
         ↓ periodic snapshot
[Git repository]               (GitHub/Forgejo)
         ↓ CI build
[Static site]                  (Astro/Starlight → Cloudflare Pages)

• GitHub is using CRDTs internally (Eon project) for keystroke-level sync
• Logseq attempted this (file + DB hybrid) and struggled
• Relay plugin for Obsidian uses CRDTs for live multiplayer on top of local files
• AFFiNE (BlockSuite + OctoBase) is the most mature implementation

Question: should cyberbaser adopt a hybrid (CRDT for live collab, git for archive), or is the complexity not worth it for v1?

Context to read first

• Principles — especially Principle 1 (GitHub is SSOT) and Principle 5 (vault is primary)
• Architecture — current technical design
• Operational Landscape — Tier 4 (operations) is where SSOT choice matters most
• Vault collab mining — collaboration models surveyed
• Vault tech stack mining — sync/CRDT section (50+ links)
• RESEARCH_SOURCES: sync/CRDT section — full link collection

What success looks like

• SSOT alternatives matrix: system name, storage model, sync model, real-time (Y/N), contribution model, self-hostable (Y/N), Obsidian-compatible (Y/N), git-compatible (Y/N)
• The “9/10 requirements” test: does git still score highest when evaluated against cyberbaser’s actual requirements (branching, PR review, atomic commits, diffing, media, access control, API, history, low barrier)?
• Hybrid architecture assessment: is CRDT + git viable for v1, or is it a v2 investment?
• The strongest “abandon git” argument: steel-manned. What would cyberbaser look like on AFFiNE’s stack (OctoBase + BlockSuite) instead of git? What’s gained, what’s lost?
• The strongest “keep git” argument: steel-manned. Why is git-as-SSOT + CMS abstraction layer the pragmatic choice even with the tension?
• Recommendation: keep, modify, or replace Principle 1 — with evidence and a validity date

Validity: this analysis holds until one of these happens: (a) Obsidian ships native CRDT sync for shared vaults, (b) a git forge ships built-in wiki contribution UX that matches Decap’s Open Authoring, or (c) a CRDT wiki with git export reaches production maturity.

What this does NOT decide

• CMS choice (that’s Challenge 02)
• Whether to add real-time collab to v1 (that’s the collaboration model roadmap task)
• Hosting provider (Cloudflare vs alternatives)
• The final architecture (this evaluates the SSOT layer; architecture is the full stack)

Related

• Challenge 05: Translation equivalence — round-trip fidelity depends on the SSOT format
• Challenge 06: Scaling + infrastructure — repo size limits are a git-specific constraint
• Challenge 08: Linchpin audit — SSOT choice is likely a linchpin