An ephemeral viewer: request, Core worker, escaped HTML
이 상세 자료는 아직 한국어로 번역되지 않아 영문 원문을 표시합니다.
Unverified 공개 출처와 지원 범위
- Status
- Unverified
- Component
- Web viewer
- Deployment
- Web service (viewer.thegram.one; submission endpoint not verified)
- Applies to version
- Latest
- 출처 확인일
- 미확인
- Owner
- Unassigned
- Public evidence
- None
- Basis
- The page describes an ephemeral submitted-file renderer, but fetching the public viewer endpoint failed, so current public availability and status are unverified.
All pages: version and status matrix
출처 확인은 실제 계정 설치·기기 동작·서비스 상태의 검증을 뜻하지 않습니다.
A viewer, not a hosted document library
Section titled “A viewer, not a hosted document library”The existing web renderer solves a narrow problem: let a person inspect a submitted .gram file in a browser without requiring an account or storing a document collection. The brand-monochrome checkout at 254a49d is a local worktree of this same renderer repository, not an independent repository or separate product. The API accepts a multipart POST containing source bytes or text, sends it through Core, and returns render data. The /view path returns a page. Since a later GET cannot recover an earlier submission, the browser must submit the file again when it asks for another revision. This is a distinct product shape from Vault, which owns identity and storage APIs.
The separation is important for both product expectations and privacy. There is no document ID registry, account session, sync service, database, or saved sharing link in this viewer contract. The server handles submitted bytes in request memory and forgets them after responding. Request logs are documented as a fixed schema without query, header, or body values. That reduces persistence surfaces, but it does not mean the server never receives the document: the user explicitly submits bytes to the service.
One shared record vocabulary over one submission
Section titled “One shared record vocabulary over one submission”Core renders a view from the document’s shared record vocabulary; the retired per-type templates no longer choose different dashboards. The Viewer displays the returned view without changing the canonical .gram source. See Document views and record types for current record semantics and evidence rules.
One folder home for several files
Section titled “One folder home for several files”Several submitted files open one folder home from Core WorkspaceView/1 at their current revisions. The default is not a list of eight screens, and there is no screen selector or query toolbar. Revision, at and expected_hash selectors belong to a single document, not a workspace. The browser retains the submitted file Blobs only in tab memory; it does not save documents or create a combined .gram file. The explicit legacy built-in-view API remains distinct from the default folder home.
Request path
Section titled “Request path”A browser or command-line client sends a multipart/form-data POST to /api/v1/render, /api/v1/search, or /view. A field chooses one input representation (file or source) and optional selectors such as revision, at, history, history_offset, or html. The service validates field cardinality and size, then invokes Core in a fresh worker process. The worker receives document input on stdin and returns structured results on stdout. Time, memory and concurrency limits bound the work; failures are explicit errors such as E_LIMIT, E_STALE, E_BUSY, or E_TIMEOUT.
Core history and replay supply the selected source and projections. The HTML renderer escapes document values, restricts links to safe schemes, and does not emit document-provided scripts, styles, or images. Unsupported blocks are retained as source with an unsupported-content indication. The browser keeps a selected file in tab memory and posts it again for state changes; the documented implementation avoids browser Storage APIs, service workers, and putting document text in the URL. A content security policy and no-store responses further constrain page behavior.
Example: render one selected historical state
Section titled “Example: render one selected historical state”For a local file named plan.gram, a client can submit file=@plan.gram and revision=2 to /api/v1/render; to ask for an HTML fragment, include html=1. A caller should handle a 422 Core history error, a 413 size cap, and temporary 503 worker saturation rather than claiming every source produces a complete view. The renderer may return summary metadata for old states while some detailed change projections are bounded by a source-byte budget. A rendered view is a projection, not a rewrite of the original document.
The branded worktree is not a separate service
Section titled “The branded worktree is not a separate service”The local brand-monochrome git worktree is based on thegram-web-render at earlier commit 254a49d. Its remote is the same renderer repository; it is not a separate product repository or independent service. The difference is a local snapshot, not evidence of another identity store, deployment, or retention model.
Tradeoffs and limits
Section titled “Tradeoffs and limits”A stateless renderer avoids account friction and server-side document libraries, but it requires sending the bytes on every interaction and does not create a durable share URL. HTML output is safe by default and may omit unsupported rich content or show raw source; this is not a full fidelity promise for every format construct. Resource caps protect service availability but mean a large file or busy worker pool can fail. Public access and ephemeral handling do not equal confidentiality guarantees beyond the described processing and logging boundary. A user handling sensitive data should decide whether the service is appropriate before submitting it.
Use the history walkthrough to compare actual Core-replayed states in a downloadable .gram file. The renderer's API and deployment source records below describe the checked contract; source configuration alone does not prove current deployment.
Sources
Section titled “Sources”Implementation claims use both renderer checkouts' README, API and deployment documentation.
Source
Section titled “Source”Source: Renderer README and browser flow
Internal source reviewed at revision 971a0474fb4b97c3d23d6687be80664461f43a2f (main: README.md); not publicly available.
Source: Renderer HTTP API contract
Internal source reviewed at revision 971a0474fb4b97c3d23d6687be80664461f43a2f (main: docs/api.md); not publicly available.
Source: Renderer deployment configuration documentation
Internal source reviewed at revision 971a0474fb4b97c3d23d6687be80664461f43a2f (main: deploy/README.md); not publicly available.
Source: Branded renderer README
Internal source reviewed at revision 254a49d8adb6ccb98675a0511283f511914394c9 on branch brand-monochrome (README.md); not publicly available.
Source: Branded renderer API contract
Internal source reviewed at revision 254a49d8adb6ccb98675a0511283f511914394c9 on branch brand-monochrome (docs/api.md); not publicly available.
Source: Branded renderer deployment documentation
Internal source reviewed at revision 254a49d8adb6ccb98675a0511283f511914394c9 on branch brand-monochrome (deploy/README.md); not publicly available.
Knowledge
Section titled “Knowledge”Knowledge: Renderer processes submitted documents ephemerally
The request path uses worker processes and in-memory document processing without a persistent document store in the documented contract.
Reference: → Supports: A bounded worker turns Core output into HTML
Knowledge: A bounded worker turns Core output into HTML
Fresh workers, resource limits, escaping and restricted browser behavior constrain untrusted document rendering.
Reference: → Supports: The branded checkout is not proof of a separate service
Knowledge: The branded checkout is not proof of a separate service
Similar API and deployment docs describe a checkout distinction; operational independence requires separate evidence.
Knowledge: A stateless viewer still receives document bytes
No storage does not mean no transmission; a user must decide whether the chosen document is appropriate to submit.
Reference: → Supports: Renderer processes submitted documents ephemerally
Source and renderer evidence
- Canonical source SHA-256
7bb5a07a799d92c53a11d0a2ffba01002978c85e89fc69b9911b1b5d13d4a010- Selected revision
r9 · sha256:e4b190148fcc3226b97425d0a3d9df22d96ffc0da2a1ee5b03c2aef19e40921a- 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: viewer-architecture.gram