@gram 2
doc blog-web-and-distribution
t The product site, web renderer, and desktop delivery are separate
d How to distinguish informational web pages, browser rendering, and Mac package channels without implying deployment or release guarantees.
tag architecture
view document

::rich
# Three different meanings of “the web”

Thegram has a public product site, an existing browser renderer, and native Mac software. These are related entry points but not one delivery system. The product site explains product and installation routes; the renderer accepts document bytes and produces a view; Desktop is an application installed and run on macOS. A statement about one surface does not prove availability, privacy model, or release status of another.

The `thegram-web` README describes a static site with pages for product information, install instructions, legal terms, privacy, and download guidance. Static content can explain how to obtain an application, but does not itself build or ship that app. Its README documents an intended cluster route and deployment setup alongside the source; repository configuration is not independent proof that a particular deployment is currently healthy or accessible.

## Browser reading is a request, not a hosted workspace

`thegram-web-render` documents a no-login viewer. A user can paste or upload a .gram file, inspect its document or dashboard view, and navigate history. The browser submits source via POST; the server processes it ephemerally and does not retain documents for later retrieval. No reusable sharing link or synced library follows from opening a file in this interface. It is useful for quick reading where submission is acceptable, but not a replacement for a local file owner or team storage service.

## Native package routes

The primary desktop repository README states a public Mac version and points to the public DMG endpoint. The separately maintained `thegram-desktop-appstore` README describes a different TEST line: it says the official release is blocked by unresolved Core licensing and acceptance gaps. These facts must remain separate. A test DMG is not an official App Store or general release. A public download URL in a README does not by itself establish current status of every package, its license conditions, or store availability.

For iOS, the README describes a read-only iPhone/iPad viewer and the product homepage calls the current route a TestFlight beta. Website wording is time-sensitive; readers should follow the current official page rather than infer an App Store release. iOS import behavior also differs from desktop editing and from the renderer’s upload flow.

## Example: choose the right route

A Mac user preparing a decision brief can edit the canonical file in Desktop, preserving its history. A reviewer on a phone can open the same file in the iOS reader, but cannot author changes there. A recipient who does not need durable account storage can submit a copy to the browser renderer, accepting the transmission and renderer’s limits. A link to the public product page is for instructions and discovery, not a private document URL. A team that needs shared storage should evaluate Vault authorization separately rather than assume the renderer stores uploaded files.

## Distribution and evidence boundaries

A distribution claim should name its channel (public DMG, local TEST DMG, TestFlight invitation, or browser service), owning repository, and evidence date. A website may be static source; a package may be signed but blocked from release; a service may have deployment manifests without a live health check. These are different evidence classes. Do not turn a package README into a live availability claim, or write that a site or service was deployed unless deployment evidence was actually checked.

Further reading: `thegram-web/README.md` for site routes and crawlable pages; Desktop and App Store README/acceptance for the Mac lines; the iOS README and homepage for current beta wording; renderer API and deployment docs for the browser path. This article makes no deployment action, account change, or release claim beyond those sources.

## Sources

The comparison follows the checked website, native client, App Store test line, iOS, and renderer entry points.
::end

SRC web-readme
d Internal source reviewed at revision 944ad8fb276bf14c50268816a85b779856b90406; not publicly available.
t Static product website README
SRC desktop-readme
t Desktop product README
ref https://github.com/clab-one/thegram-desktop/blob/main/README.md
SRC appstore-readme
t App Store test-line README and release status
ref https://github.com/clab-one/thegram-desktop-appstore/blob/main/README.md
SRC appstore-acceptance
t App Store test-line acceptance
ref https://github.com/clab-one/thegram-desktop-appstore/blob/main/docs/acceptance.md
SRC ios-readme
t iOS read-only viewer README
ref https://github.com/clab-one/thegram-ios/blob/main/README.md
SRC site-home
t Current public product homepage
ref https://thegram.one/
SRC renderer-api
t Existing renderer API contract
ref https://github.com/clab-one/thegram-web-render/blob/main/docs/api.md
K surface-separation
t Product site, renderer and native clients have different roles
d Documentation pages, byte-submission rendering and local application workflows have distinct persistence and delivery boundaries.
source web-readme
source renderer-api
supports channel-confusion
K channel-confusion
d Public DMG, local TEST DMG, TestFlight invitation and browser access are different channels; identify each source and date.
source desktop-readme
source appstore-readme
source appstore-acceptance
t Distribution labels can conceal different release gates
supports surface-separation

K deployment-claim
d Public availability requires current service or release evidence, not only a repository URL or manifest.
source web-readme
source site-home
t Do not infer deployment from configuration alone
supports surface-separation