Skip to content

Thegram as a product: durable knowledge across apps · r1

Archived revision r1, recorded 2026-10-12T08:13:38.658Z. Current page: Thegram as a product: durable knowledge across apps.

Thegram is best understood as a portable knowledge artifact with multiple ways to author, inspect, and share it—not as one editor or a hosted database. A .gram document keeps the current meaning and a recoverable history together. A reader can inspect the latest state, follow explicit relationships, and ask what the same file said in an earlier revision. That makes a task, decision, evidence, and source legible as a connected account rather than a transient chat answer. The thesis is practical: preserve the context around why work changed, while keeping the canonical file usable outside any one client.

The product should not be confused with a claim that every surface has identical capabilities. Core defines document semantics and history; applications own interaction and derived views. Search indexes, vectors, graph layout, caches, and HTML are projections. They can be rebuilt and do not replace the source file. Authentication and storage access are service concerns, not fields encoded by a .gram label.

  • thegram-format owns the Rust Core, grammar, canonical meaning, validation, history replay, transaction operations, and projections. Current writes use @gram 2 with History/6; this repository is the authority for parsing and persisted revision behavior.
  • thegram-desktop is the macOS SwiftUI product: local file interaction, editing, graph/time experiences, and optional remote account or storage connections. Its README reports public version 0.9.6 build 31, but its license status and precise evidence scope still matter; a version number is not a general feature guarantee.
  • thegram-desktop-appstore is a separate local TEST application/DMG line. Its README and acceptance file explicitly say the official release is blocked by unresolved Core licensing and incomplete acceptance items. Do not merge its test milestone with the other desktop repository's release status.
  • thegram-ios is a read-only iPhone/iPad viewer. It opens chosen folders/files and can show downloaded Google Drive copies; editing is not an iOS capability.
  • thegram-web is the public product/installation information site. Site content and download routing are distinct from a running document reader.
  • thegram-web-render is the existing ephemeral, unauthenticated web renderer. It accepts submitted document bytes and renders them without retaining them as a hosted library.
  • thegram-web-render-brand is a parallel branded checkout of that renderer, not evidence of an independent storage product or separate deployment.
  • thegram-vault supplies identity, storage APIs, and Google Drive integration. Its account and storage functions are not the same as the renderer's stateless POST flow.
  • thegram-plugin packages a cloud MCP integration and reference material for agents. The current contract distinguishes cloud tools from local agent integration.
  • thegram-memory installs local coding-agent hooks/adapters that use a running Mac app and configured write access. Its project-folder mapping and injected brief are local integration behavior, not a cloud guarantee.

A user can author on Mac, read on iOS, or submit a file to the web renderer, but should check each surface's actual boundary before relying on it. For example, a Drive-backed iOS entry is described as a read-only downloaded copy; that does not imply editing the provider file. A public website's install instructions do not prove that an account, release channel, or deployment is available to every reader. Similarly, desktop local mode and Vault-connected mode have different network and identity implications.

For an individual decision, keep the canonical .gram in the location the owner chose, include records for the decision and evidence, and link the evidence with explicit predicates. Use Desktop when native editing is needed; use iOS for portable inspection; use the viewer for a one-off rendering after deciding that submitting bytes to the service is appropriate. A team needing account-backed shared storage should examine Vault and its authorization contract separately. An agent should use the approved plugin path for its environment rather than assuming all interfaces share the same credentials.

The repositories describe current implementation, not feature parity, a future roadmap, adoption, or commercial traction. The app-store checkout's release gate is materially different from a local test build. The web renderer is not a file-sync system. Start with the format README and language/architecture specifications, then read each client README, the Vault service spec, the renderer API contract, and the specific plugin installation guide. For operational or release claims, prefer the owning repository's current acceptance evidence over a summary page.

This map is grounded in checked repository entry points and the public product landing page; availability labels intentionally follow those sources.

Source: Format Core README and specifications

Internal source reviewed at revision 625edecee877ddf5f6c303cb478c64fa4cbca651; not publicly available.

Source: macOS desktop README and UI design

Reference: https://github.com/clab-one/thegram-desktop

Source: Desktop App Store test line and acceptance

Reference: https://github.com/clab-one/thegram-desktop-appstore

Source: iOS read-only viewer README

Reference: https://github.com/clab-one/thegram-ios

Source: Product website and install documentation

Internal source reviewed at revision 944ad8fb276bf14c50268816a85b779856b90406; not publicly available.

Source: Ephemeral web renderer API and architecture

Reference: https://github.com/clab-one/thegram-web-render

Source: Branded renderer checkout

Reference: https://github.com/clab-one/thegram-web-render-brand

Source: Vault implementation and service specification

Internal source reviewed at revision a193a190141054e07b268f0a38489467db82a335; not publicly available.

Source: Agent cloud plugin contracts

Reference: https://github.com/clab-one/thegram-plugin

Source: Local agent memory integration

Reference: https://github.com/clab-one/thegram-memory

Knowledge: Portable knowledge with recoverable history

The canonical file carries current meaning and history while clients provide distinct projections and interactions.

Reference: → Supports: The file is canonical, derived indexes are not

Knowledge: The file is canonical, derived indexes are not

Search, graph, HTML, and cache outputs are rebuildable projections rather than alternate sources of truth.

Risk: Client capabilities are not interchangeable

Editing, importing, identity, network handling, and persistence differ by surface; verify the owning contract before relying on a feature.

Reference: → Supports: Portable knowledge with recoverable history

Source and renderer evidence

Canonical source SHA-256
8d7508eb4ef6a28b735b1925e346ca1ca78f690d451c171dc0cc274352893116
Selected revision
r1 · sha256:facc8fb9644d95bb3f8419921ced4688cc95bc5abc3b6e275e663888ea53aabe
Local renderer
configured local Thegram renderer · API thegram-web-render/1
Core source
git+https://github.com/clab-one/thegram-format.git?rev=b16489e1d0d77d38f82d2f61776524737aa31557#b16489e1d0d77d38f82d2f61776524737aa31557

Canonical source: 1.gram