Pages#

HyperNetPage/2 is an inert text format. A publication binds the exact source, author, reviewer, network and incarnation, namespace, Page identity and revision. Changing the source requires a new signed submission and review. The authority orders Page metadata and verifies the immutable objects used by each operation.

Document and publication contract#

The HyperPage specification defines the grammar, component attributes, layout bounds and finite actions. Containers, scrollboxes, buttons, forms and media references are declarative. There is no script, HTML interpretation, arbitrary API command or automatic network action. Effects run in the viewer from approved parameters; the network does not carry animation frames generated by an author program.

Source is at most 16 KiB and is hashed without normalisation or reformatting. Only HyperNetPage/2 is accepted. Grapheme segmentation is pinned to unicode-segmentation 1.13.3. Changes to accepted semantics require an explicit contract and signature-domain assessment. Plain moderation includes all container contents and action destinations, including text outside the initial scrollbox viewport. Approval does not guarantee harmless or truthful content. Reader colour, motion and layout preferences cannot change the approved bytes.

An author signs a detached PageAuthorStatement using the ordinary canonical Intent envelope. It names the exact source object, native Page identity, namespace, revision, current grant and any native application policy. This is portable provenance, not a command that can independently publish content. Submitting it creates an immutable revision and advances the Page ledger's pending head. An existing approved revision remains published while its replacement is pending or rejected.

Submission uses a signed causal floor and exact relevant record versions. Another requester's read or maintenance receipt may commit between authoring and submission without invalidating it. At submission's commit, the authority still checks current publishing rights, the Page owner and next revision, native application policy, media host consent, placement and capacity. A changed or withdrawn dependency refuses; the old authoring context cannot supply current permission. The same current-dependency rule applies to review and other finite Page mutations.

A reviewer obtains the exact pending source through an authorised inspection, then signs a detached PageReviewStatement. It binds that revision and source, the author statement, reviewer grant, application policy if applicable, review mode, policy digest and decision. Approval supplies the exact approved bundle; rejection supplies no bundle. The bundle contains source and both statements, and is at most 56 KiB. The authority rechecks their correspondence and current permissions before committing the decision. Review statements have a bounded five-minute submission lifetime; a committed approval does not become invalid merely because that submission deadline has passed.

Withdrawal clears the pending and published heads while retaining their exact history. It prevents fresh authorised reads of the withdrawn publication. Neither withdrawal nor a later policy change erases bytes previously obtained by an authorised reader or host.

Permissions and applications#

Reading, publishing and review require current ReadPage (0), PublishPage (2) and ReviewPage (3) capabilities respectively, with matching scope and limits. Hosting requires HostPages (5); namespace media placement policy requires AdministerPlacement (21). These are separate from service registration (13) and local runtime management (26). Membership or a service role does not imply any of these rights.

A native application also needs its current application admission, exact grant and a Page application policy signed by both owner and application. The policy restricts namespaces, optional Page identities, review modes and expiry. Both the detached author or review statement and execution name the exact policy version. Application signatures retain the application's identity, and fresh operations recheck its owner's rights and withdrawal state. Manual review is the default; automated review requires explicit delegation and policy. See Applications and PolicyContract.

Certified views#

["PageView",pageBytes16] is one read-only AuthorityDomain operation. It checks PageRead's exact published revision, signed approval, media metadata and current reader/application authority, then evaluates PageContentGet for that exact placement in the same ordered state. The selected placement must be live; its owner's separate right to inspect withdrawn metadata cannot authorise a view. The result carries the union of both dependency closures, current host records and copy metadata, with the earliest applicable expiry. The ordinary challenge, quorum proof, retained floors and result bounds apply unchanged. Source bytes do not enter this authority result.

A verified view replaces two separate metadata requests. It does not authorise an old content host or bypass a later byte effect: a selected service still checks current exact publication, placement, host consent and recipient rights when serving. PageRead and PageContentGet remain available for metadata inspection, including their existing unavailable-storage distinctions.

Objects, delivery and resource bounds#

Source and bundles are immutable objects with typed, length-bound SHA-256 references. A submission transmits its declared source; an approval transmits its declared bundle. Evaluation can also require an already retained source. Missing or mismatched objects prevent local progress; they cannot turn an incomplete evaluation into an ordered policy refusal or approval. Checkpoints and healthy committee replacement retain the complete object closure of Page history, including pending and withdrawn records.

An authorised inspection or read selects exact object references from its certified result. Delivery attaches precisely those objects. Clients verify the quorum result, current retained authority state, object hashes and publication provenance before releasing bytes. An object reference alone is not read authority. Retained request journals support an exact retry after interruption without generating a new author or reviewer statement.

Admission charges the current signed resource limits for source, declared media and operations. Canonical record, state, object and certified-response budgets also apply. There is no separate fixed lifetime Page count per author. Discovery uses bounded pages and explicit continuation cursors. Replica tickets have a maximum sixty-second reservation and charge current reader and host concurrency limits. Individual proofs remain bounded to five seconds; every hop rechecks current authority and the ticket's 1, 250-millisecond expiry margin. An expired slot can advance to a new generation without losing its prior identity. A pending replica result contains current authorised metadata without bundle bytes. After delivery, the result requires the exact ticket bundle and its approved provenance; missing or substituted bytes cannot complete the read.

Hosting withdrawal uses exact certified owner context, including for a fresh operator cache after deployment expiry, revocation or withdrawal. Only the recorded manager or operator can obtain that context without a discretionary grant. This historical ownership permits restriction, not renewed content access or serving.

Media requires the exact approved descriptors, consented hosts, copy receipts and reviewer inspection evidence described in PageMedia. Forms remain inert Page content: sending requires an explicit user action and current Mail authority, including SendMail (15), rather than permission inferred from Page approval. The current Page evaluator supports host-readable publication. Sealed publication and a reader relay route have separate contracts; Page metadata approval does not establish either guarantee.