Ting delivery verification — 2026-09-23#

These checks use disposable local IAM, Ting and Hook services. Reports cover published Ting 0.1.2, 0.1.3 and 0.1.4; each versioned group identifies its tested paths. They do not establish production deployment or publication of Hook 0.8. The fixture and reproduction commands are in the E2E guide.

Verified delivery paths#

The non-secret reports record correlated Hook/Ting IDs, original-payload hashes, executable hashes where captured, individual assertions and coverage limits. Reports cover successive implementation stages; their executable hashes identify those stages rather than implying every historical run used the final binary.

Ting 0.1.3 verification#

The official server and native archives were checked against their published SHA-256 sums at source revision 115954f074a9dfd48e3f14b39a70ecaf8cc7a6c5. The owned server database and native queue were copied while both services were stopped; the earlier containers, data and 0.1.2 reports were preserved. The existing recipient session survived the upgrade and /v1/me returned environment: {kind: "production"}.

Backend publication, native delivery/read ACKs, SDK durable acceptance and restart/replay, final CLI send/receive and publisher provisioning, unavailable-original queue progress, website HTTP and actual Chrome flows all passed again. The nine new reports are grouped under ting_0_1_3 in the JSON record, and the CLI/website binary hashes identify the builds tested at that stage. The production website path requires this explicit production attestation before activating or resuming receiving. Regression tests reject missing, malformed, testing and conflicting-generation context while preserving credentials for cleanup. Older Ting servers without the attestation cannot activate website receiving.

Ting 0.1.4 compatibility and recovery#

The official server and native archives were checked against their published SHA-256 sums at source revision 3253ea193c9fc244e6ef7e5fd818240ae0ad4782. Upgrade retained the older data/reports and verified a migrated recipient session plus a fresh native CLI login/status/logout.

Existing Hook backend publication, native delivery/read ACKs, SDK restart recovery and website HTTP receiving passed. The SDK hydrated an exact 300,098-byte provider body from a 695-byte callback; daemon and host restart produced two requests, one new event and one durable duplicate. Website paired replacement, Carbon watching, exact 300,121-byte hydration, unread observation and logout passed. Browser rendering and the Hook CLI were not rerun in this bounded upgrade check.

Login replay after 125.006 real seconds returned 200 with the identical original response. After deletion, replay returned 401 session_expired and the credential remained revoked. This independently verifies the retained-operation recovery fix. The first response was captured privately as the comparison and cleanup credential; no packet loss was injected. Legacy results erased by older releases were not recoverable in this test.

Six sanitized reports are grouped under ting_0_1_4. These checks precede Hook's adoption of scoped receivers and required delivery and do not prove those new integration paths.

Ting 0.1.4 adoption#

New primary Hook sends were refused with required_delivery_not_enabled until the disposable recipient explicitly opted in through its own Ting session. The normal scheduled worker retry succeeded after 301.023 seconds, preserving the exact request body and operation key. Muted required delivery reported accepted_by_ting, delivery: "required" and silent: true. The published native daemon delivered the exact original, with delivery ACK before the callback response and read ACK only after HTTP 204. Original recipient preferences were restored.

The updated Rust SDK also passed muted required delivery with the actual native daemon. Its 300,098-byte original arrived through a 696-byte callback. Restarting both daemon and SDK host produced two requests, one new durable acceptance and one duplicate; HTTP 204 then produced the read ACK. The fixture restored its original recipient settings.

A separate real IAM testing-plane fixture verified Carbon and Silicon bootstrap, exact replay, generation rejection, revocation and inability to use the capability as an ordinary Ting session. The actual Hook worker then published a signed 300,097-byte request: both actors received scoped watch hints and read their own app inbox, and current Hook authority hydrated the exact bytes. Primary required delivery and the ordinary Carbon copy remained distinct. Renewal replaced the old token, reconnect recovered the same unread record, and scoped observation sent no read ACK.

Actual shared clean advanced generation 1 to 2 and invalidated both receivers and the old Hook selector about 29.34 seconds before capability expiry. The environment was rebuilt through the authenticated lifecycle for subsequent checks. Rotation and restore are not claimed by this clean test.

The real CLI used only Hook's selected test app secret and a Hook-bound SLT. Its SDK calls passed scope discovery, identical key/body replay into separate 0600 files, explicit same-ID renewal, stale-generation rejection and revocation that survived historical replay. No capability appeared in stdout, stderr or the profile; private files were removed and its dedicated Hook family logged out. This caught and fixed fresh-profile backend binding during env use.

The final website build also passed normal-plane paired HTTP and actual Chrome verification: exact 300,121/300,124-byte payloads, unread observation, publication inspection, logout/revocation and desktop/mobile layout. Public negotiation now omits test selectors, matching the SDK; versioned testing calls retain them.

The scoped website HTTP flow used only Hook’s test selector and Hook-bound SLT. After 35.091 seconds it had automatically renewed the same receiver ID with a new capability. Exact 300,133-byte ordinary and 300,127-byte silent arrivals reached the view, both recipient copies stayed unread, and logout revoked the capability. Recipient settings were restored.

These reports are under ting_0_1_4_adoption. Actual scoped Chrome also passed Hook-only UI sign-in, 35-second renewal, exact 300,124-byte silent delivery, payload/publication inspection, no read ACK and logout. The corrected testing header and production header both fit a 390px phone viewport; the events table scrolls independently. A separate real backlog test sent 32 signed requests and published all 64 primary/observer copies. The same live stream paused at 22 forwarded events on an actual IAM rate limit, renewed the same receiver, then completed all 32 with zero duplicate frames. All 32 scoped records remained silent and unread. IAM limits and clocks were unchanged. The fixture uses actual authenticated participant APIs and official test identity creation, but does not run the full Honeycomb coordinator. Notification-type provisioning is seeded in the owned fixture; production approval is not established.

The idle-worker fix consumed zero IAM application quota units during 30.158 seconds at the default one-second worker interval with no due work. Before the fix, idle context resolution and redundant browser scope lookups exhausted the 120-unit bucket; the diagnostic and fixed-runtime reports are preserved separately.

Final cleanup advanced the rebuilt shared environment from generation 2 to 3 through official participant APIs. Carbon and Silicon capabilities and the old Hook selector were rejected about 28.98 seconds before the original capability expiry. A stale cached IAM revision was refreshed from the authenticated official record before cleaning. The generation clean also fenced one synthetic observer whose token was lost during an earlier failed harness attempt; that individual token was not available for a separate check.

Both owned fixture stacks are stopped. Their containers, data, private archives and logs are retained; unrelated services were not touched.

Historical upstream recovery limitation#

A separate real HTTP check confirmed the Ting 0.1.3 login recovery gap: initial login returned 201, immediate exact-key/body replay returned the identical response with 200, and the same replay after 125 actual seconds returned 401 session_expired. The original session still authenticated with 200. Deleting only that new session succeeded and subsequent authentication returned 401.

This report appears separately under upstream_limitations, not among the successful recovery paths. The first response was retained privately to observe and revoke the session; an actual lost packet or production outage was not simulated. The corresponding missing-response risk is inferred from this replay result and the source contract. Reproduction uses scripts/ting_e2e/login_recovery.py; the private operation credential was removed after confirmed revocation.

Local regression checks#

The Rust workspace passes 254 tests: 196 backend tests, 29 client tests and 29 CLI tests. One opt-in Space Station test remains ignored. The backend tests use restricted PostgreSQL roles and cover atomic rollback, signature rejection, 1 MiB payload hydration, uncertain send responses, retry identity, publisher recovery, current Carbon authority, permission loss and environment cleaning/generation fences. The final SDK/CLI additions test publisher provisioning/recovery with explicit mutation identity, private file/stdin input, organization/test context, safe metadata and permission failures.

Workspace Clippy with all targets/features and warnings denied, formatting, rustdoc with warnings denied, dependency policy checks and OpenAPI validation passed. All 36 website tests, TypeScript checking and the production build pass. Browser screenshots were inspected after the mobile overflow fix and the final Ting 0.1.4 rerun; their paths and measured dimensions are in the browser reports.

The real website run exposed and verified fixes for canonical Hook organization handles versus Ting UUIDs and a mobile accessibility label escaping its table's scroll container. Gateway regressions also cover interrupted/replayed sign-in, credential replacement/cleanup, failed logout, current Carbon authority renewal and bounded inbox observation without ACKs.

Coverage limits#

• The historical compatibility reports use the isolated normal plane. The 0.1.4 adoption reports additionally cover real IAM testing-plane bootstrap and Hook scoped delivery; CLI, scoped HTTP/Chrome lifecycle and real rate-limit catchup checks pass.
• The notification type was seeded in the fixture. This does not verify operator provisioning through Honeycomb.
• Publisher provisioning used a separate backend/database, which were removed after verification. Management and Ting sessions were revoked; synthetic Silicon IAM sessions remain confined to the disposable IAM fixture until its cleanup because IAM does not support Silicon logout-all.
• The official IAM CLI performed real atomic batch issuance and consent for the disposable identity. The browser executed the actual callback and application flows; IAM's hosted consent webpage and a hosted HTTPS deployment were not exercised.
• The durable receiver is the actual SDK example host, not an external application's business logic. Acceptance never proves completed work.
• The retention check removes selected fixture payloads rather than waiting 14 days. Its final duplicate callbacks are controlled local replays; initial and subsequent delivery use the real native daemon.
• Windows private-file ACL implementation was source-inspected; runtime verification is unavailable, and cross-compilation stopped in a dependency because Windows SDK headers were absent.
• Lost receiver replies followed by loss of the original authority retain cleanup uncertainty. This was reviewed and reproduced in memory, not as a live network outage plus clean.
• Ting integration issues records remaining cleanup uncertainty, recipient opt-in and official production approval gates.