Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

RFC-0001: typub: a typst-first local cms

Version: 0.1.0 | Status: normative | Phase: stable

1. Summary

[RFC-0001:C-SUMMARY] Summary (Informative)

Typub is a local-first, Typst-first CMS intended for writers who want plain files, deterministic rendering, and multi-platform publishing without surrendering ownership to a hosted editor.

This RFC establishes the project vision and boundaries for RFC-0001. It is intentionally informative and does not define normative protocol or API requirements.

Scope for RFC-0001:

  • Define the high-level product identity and target user workflow.
  • Define the principles that guide future normative RFCs.
  • Define explicit non-goals to prevent accidental scope creep.

Out of scope for RFC-0001:

  • Adapter-specific API contracts.
  • Storage and schema contracts.
  • Detailed CLI or renderer behavior guarantees.

This RFC is vision-only by design. Normative requirements will be introduced in subsequent RFCs.

Since: v0.1.0

[RFC-0001:C-VISION] Product Vision (Informative)

Typub is intended to be treated as a writing system first and a distribution system second.

Vision pillars:

  1. Typst-first authoring

    • Typst is the primary source format.
    • Markdown support exists for interoperability, not as the design center.

  2. Local-first ownership

    • Content, metadata, assets, and publish status remain local project artifacts.
    • Platform integrations are adapters, not sources of truth.

  3. Multi-platform by composition

    • A single source post can be transformed and published to multiple targets through adapter boundaries.
    • Platform divergence is expected and should be isolated behind adapter contracts.

  4. Deterministic pipeline

    • Rendering, transformation, and publish steps should remain auditable and reproducible from repository state.

Rationale: This direction aligns typub with long-lived technical writing workflows where files, version control, and portability matter more than SaaS-native editing UX.

Since: v0.1.0

[RFC-0001:C-GOALS] Goals and Non-Goals (Informative)

Goals:

  • A clear authoring-to-publish flow centered on local files.
  • Platform adapters that preserve core intent while allowing target-specific output constraints.
  • Governance readiness so future implementation RFCs can reference RFC-0001 as baseline intent.

Non-goals:

  • Becoming a hosted CMS.
  • Enforcing identical output semantics across all publishing targets.
  • Abstracting away every platform limitation at the cost of architectural clarity.

Forward references: Future normative RFCs SHOULD reference RFC-0001 for product alignment and define concrete MUST/SHOULD/MAY requirements at the feature level.

Since: v0.1.0

2. Specification

[RFC-0001:C-SPEC-PLACEHOLDER] Specification Scope Note (Informative)

This section intentionally contains no normative clauses in RFC-0001.

Normative requirements (MUST/SHOULD/MAY) will be specified in follow-up RFCs that cover concrete behavior and contracts.

Since: v0.1.0

Changelog

v0.1.0 (2026-02-11)

Initial draft