What travels through an AmoosedWeb site.

One index, many verified resources

The compiler starts with an ordinary site and an app. It places the app index in the site's discovery favicon by default, then assigns app resource parts to existing media files. The host serves ordinary pages, the favicon, media, and the site-owned runtime routes. A Reader or browser runtime uses the index to locate and check every part before exposing a reconstructed resource.

The /amoosed.com/app/* paths are virtual: the same-origin worker serves them from checked carrier bytes. A Node.js, .NET, or native Reader can fetch resources without installing the browser runtime. An overlay alone cannot install the browser route; the host must also serve the site-owned runtime. See the host contract.

The AMW v1 document and its footer

An AMW payload starts with a 4,096-byte fixed header. Its manifest is UTF-8 JSON with exactly two contiguous v1 sections: bootstrap and document. The header supplies lengths, offsets, and SHA-256 digests for the manifest and bootstrap. The manifest supplies section digests. AMW integers are unsigned little endian; PNG and MP4 container fields keep their native big-endian encoding.

A footer v2 Reader may show the intro after validating its anchored prefix and section digests. Footer v1 and bare .amw readers wait for the complete document check first. The full payload digest remains mandatory before accepting the full document. See the exact header and footer tables.

Where resource parts go

The default app data carrier appends encoded parts and an AMW1DATA footer to an existing opaque file. PNG chunk and MP4 UUID modes place data inside a native container structure and retain a data footer. Pixel, tone, and frame modes encode data in image pixels or audio samples; their offsets refer to decoded payloads, so readers fetch and decode the complete media before checking shards.

The verified read sequence

For the default hosted profile, the favicon carries a public AMW index and an AES-CTR data key. The index maps each virtual resource to ordered carrier parts. The Reader checks stored bytes against the index before decoding, checks any member ciphertext before using its plaintext, then checks the assembled resource's length and SHA-256.

1. Discover and verify the index. A site root conventionally uses /favicon.ico; an explicit carrier URL can also be opened.
2. Find the resource entry and retrieve its ordered parts. Byte-addressed carriers can use HTTP ranges; pixel, tone, and frame codecs need their complete media file.
3. Verify each stored part hash, apply the site's AES-256-CTR transform when declared, then authenticate AES-256-GCM member parts when present.
4. Assemble the resource and verify its declared plaintext length and SHA-256 before serving or saving it.

SHA-256 detects mismatch against the fetched index; it is not a publisher signature if an attacker can replace both the index and the carriers. HTTPS authenticates transport. The Reader does not fetch an unrelated original media prefix just to check its footer hash during a range read. See browser runtime behavior and host byte and route requirements.

Public, external, and member access

The hosted favicon profile makes the index and its AES-CTR key public. This transform obscures casual plaintext inspection of detached carrier parts; it is not secrecy. An external-index edition leaves the ordinary favicon unchanged and encrypts the complete index with AES-256-GCM in a byte-addressable first data carrier. The user receives a separate .amwkey, packed ICO, or equivalent AMQ1 token containing the index key and carrier locator.

A member edition may mix public and protected resources. Member parts use AES-256-GCM and a separate member key; the website CTR layer is applied afterward in the carrier. An external index credential is saved in origin-scoped IndexedDB only after the worker authenticates the current site's encrypted index and app identity. A member key is retained only in volatile worker memory after a protected chunk is authenticated; a worker restart may require entry again. A QR, URL token, or key file can be forwarded; old complete releases remain accessible to holders of matching old credentials. Read the access model and rotation limits before designing an entitlement flow.

Continue with the exact contracts

Public protocol specifications and developer examples are distributed under the protocol and developer examples license; package-specific terms control each package.