JSON Canvas – An open file format for infinite canvas data

Original Article ↗ Hacker News Discussion ↗

An open JSON-based format for “infinite canvas” whiteboard-style apps, created by the makers of Obsidian, is being pitched as a way to make visual notes and node graphs portable across tools. Commenters welcome the simplicity and alignment with Obsidian’s “files over app” philosophy, but argue the 1.0 spec is underspecified, opinionated in places, and too minimal to capture many common canvas features or novel node types. There is broad interest in the idea of a shared baseline format, alongside concerns about interoperability, versioning, and whether the design should have been coordinated with other major canvas and diagramming platforms.

Overall reception

  • Many are enthusiastic about having an open, simple format for infinite canvases and praise Obsidian for publishing it.
  • Others feel the spec is too immature to be labeled “1.0” and see it more as Obsidian’s internal format than a true community standard yet.

Spec design: simplicity vs completeness

  • The spec is very small: nodes with type/position/color, edges with from/to/color/label, plus a few node subtypes.
  • Some appreciate this “Markdown-like” minimalism as good for adoption, readability, and extensibility.
  • Others argue it’s under‑specified and opinionated: preset colors, fixed node types, unclear semantics for fields like file, backgroundStyle, and coordinates.

Interoperability, extensibility, and governance

  • Many like the goal of interchange between canvas apps, but question how far that can go when apps innovate mainly in node semantics and behavior.
  • Suggestions:
    • Baseline core spec plus extensible metadata (similar to unist or Markdown frontmatter).
    • Explicit support for custom node types, styles, and embeds (URIs, MIME types, richer link types).
    • Version field at top level; conventions for extensions.
  • Some criticize launching as a “1.0 open format” without prior collaboration with other tools; others see this as a reasonable starting point that can evolve through feedback.

Technical details & missing pieces

  • Calls for:
    • Explicit bounding box / metadata for initial view and embedding.
    • Clearer definition of coordinates, units, zoom behavior, and origin.
    • Defined z‑ordering (later added: array order = z‑index).
    • Explicit group children instead of inferring from geometric overlap.
    • More styling (stroke width/style, shapes, scribbles, transparency, routing of edges).
  • Debate over arrays vs maps for nodes, required vs optional fields, and whether “point nodes” should exist.

Format choice: JSON vs alternatives

  • JSON chosen is seen as good for tooling, web use, and text‑file philosophy; some argue SQLite or binary formats would be better for integrity and performance, others note portability, diffability, and simplicity favor JSON.
  • Comparisons to SVG, GraphML, Excalidraw, Argdown, HTML, and YAML: several argue reusing or mapping to existing standards might be wiser; others say SVG/HTML are too low‑level or complex for this semantic graph‑like model.

Infinite canvas UX

  • Mixed feelings: some find infinite canvases powerful; others find them overwhelming and poorly aligned with their mental models.
  • Suggestions include multi‑scale information density, nested canvases, and tooling that operates on subsets/viewport slices rather than whole documents.