HRC transport authority and federation profile#

Revision 6, 5 November 2026. Protocol contract · HyperNet contract map

This profile describes the implemented current-authority, privacy and remote-actor boundaries for Core 0.10.2, Suite 0.10.1 and HRC 0.1.0. Source links pin the matching upstream release commits. The qualified runtime code was built from Core a3593815b7ad04ac59f76853661705c433782032, Suite cdead8ec6ce7debb694725a87808dd2af1b769b3 and HRC 037cc258e5842a07136055f98919f0ba21636b9a; final publication changes only release documentation. Section 8 gives the native pilot results and limits. Earlier conversation, federation and upgrade evidence retains its original artifact scope.

1. Existing authority semantics#

Core already performs fresh quorum Stream::Permit reads for an exact admitted session. Only that stream's registered route endpoint can request the read. The evaluator checks the session generation and open state, original caller capability, service, route and current governance. A service owner cannot replace the endpoint requester. Inspect and the caller's slot Lookup serve different purposes. Permit evaluation

The route runtime uses these reads to renew protected transport writes. Its fresh read path verifies quorum evidence, challenges, context and retained floors. A fresh read does not append an HRC message to authority history or prevent the next authority change. Read verification · Stream renewal

The current HyperNet contract bounds ordinary stream-control challenges to 5,000 ms end to end. Committed revocation prevents new permits; a permit issued before an unknown revocation retains only its original remaining lifetime. Known local withdrawal stops further use immediately. HRC inherits this finite freshness model. It does not promise that independent authority and database commits are globally atomic. The 15-second Page-federation maintenance exception does not apply to HRC. Authority time and revocation contract

HRC's own pause, revocation, membership and agreement controls remain strictly ordered by the receiving home service. Acknowledged HRC revocation rejects effects ordered after it. This is a stronger local ordering guarantee than observing a remote HyperNet revocation, and the UI must distinguish them.

2. Fresh checks for already-received work#

The version-2 companion exposes checkAuthority alongside connect, accept, status and cancel. Its connection list and original peer context remain distinct from a fresh authority read. Socket liveness, an HRC ping, old admission evidence and status error prose cannot authorise an action waiting in an HRC queue.

Implemented upstream contract: checkAuthority-v2 for an exact active incoming connection. Core's existing endpoint remains the authority requester and the companion remains the local verification boundary. HRC receives neither an endpoint signing key nor an arbitrary authority-query facility. Core check contract · Suite API

The endpoint performs a new Stream::Permit read after the request arrives. It verifies certified authority, rechecks current gates, clock health and exact forwarding/session liveness, and signs a receipt bound to the full request. The companion verifies the signature and accepted binding before exposing typed results. Only permitted and denied carry certified observation metadata. Neither is a portable quorum proof or a reusable application grant. Changed content, another connection or a new control generation cannot reuse it.

The separate endpoint-initiated Ingress/Checks.sock channel preserves opaque application bytes and mapped ingress-directory isolation. The endpoint sees /Application/Checks.sock, not the user's native command socket, profile or unrelated files. A signed challenge/ready exchange binds the accepted binding digest, nonce, companion/endpoint instances, control generation and verified host boot. Both sides require zero monotonic/boot-time namespace offsets. Framing retains the 16,384-byte ceiling; the endpoint control schema uses its existing canonical TrustWire signed envelope, while caller IPC uses versioned JSON. HRC implements the caller boundary, not a second endpoint verifier. Canonical control schema

Capability status separates API support, authenticated endpoint-channel readiness and eligibility of an exact accepted incoming connection. Outgoing streams cannot use a receiving-end check. Version-1 payload clients retain their contract, but an HRC service requiring fresh effect checks refuses a companion without checkAuthority-v2. A temporarily unready channel yields unavailable effects; repeated status calls are not a fallback.

The companion deadline crosses Core's queue and authority read unchanged. Its authority challenge has a separate immutable ceiling at the original companion start plus 5,000 ms, decreasing with queue time even for a one-second caller wait. This supports the authority uncertainty window without extending transport waiting or permitting a late result. A renewable clock observation may be refreshed during the read; the delivered receipt is clipped by current clock validity, caller/session bounds, consent/gates and certified expiry. HRC must preserve the minimum of its original call deadline and the verified receipt's notAfterBootMs, never restart a relative lifetime, and invalidate known closure/control changes. Restart invalidates pending work. Foreign assertions use section 5; another host's boot-clock number is not comparable. SDK result lifetime

The upstream implementations allow one pending check per stream and four total checks across queued and in-flight work, including cancellation draining after reconnect. Suite pipelines requests with exact reply correlation. Core overlaps immutable network exchanges while one actor retains all challenge, current-state and durable-publication ownership. Finite cohorts prepare their captured gates before issue; unused slots can accept already-current reads only before the first completion, within four total admissions and the fixed initial round end. No readiness/lifecycle mutation occurs while that round is pending. Admission also requires the existing endpoint, stream and round-tail headroom; otherwise the original request waits for normal preparation without extending its end. A deferred queue head retains its original permit, and lifecycle work receives a fair turn after drain. The contract map gives the complete bounds.

Established-stream background renewal can start a finite cohort and share the same four immutable exchange slots with already-current checks. Its completion must still match the exact open stream and current authority before the actor installs stream permission. It produces no action receipt. Endpoint renewal, unestablished-stream renewal and authority-changing cleanup remain exclusive.

The native Suite authority connector uses two independently admitted sessions to the same pinned endpoint and replica, with at most sixteen queued exchanges. Each session keeps its original route budget. Relay and authority policies must allow these connections alongside application traffic; admission failure remains explicit. These authority sessions are separate from the companion's application stream slots. Signed request and read identifiers retain their original binding across the sessions; cleanup cannot create a new admission.

Size the registered relay profile, deployment limits and consent for all selected application and authority connections. Sixteen companion application slots, two connector sessions and two other authority routes require twenty relay slots before transport overlap. The companion limit remains sixteen, including its operator and transition reserves. Core's local authority ingress separately admits four concurrent requests. A smaller measured cohort does not qualify unused application reserves; connection allocation alone does not establish the pilot's latency or fairness gates.

The channel consumes no application connection slot. HRC admits four concurrent checks within 32 total tickets, including active work. Service-owned classes and account turns reserve capacity for both interactive operations and reads; each class uses at most three active checks. Verified delegated owners share their account limits. The permission specification defines these bounds. Queue admission never replaces current authority or final-effect checks. Section 8 qualifies the measured pilot, not every unused connection slot.

Preparation errors remain distinct from these authority dispositions. Suite reports local Capacity, accept or tagged transport Timeout, and tagged setup transport Closed; other planning/validation failures remain Refused. HRC must not treat generic Refused as a certified denial or infer safe retry from error prose. A lost connection alone cannot establish whether an earlier HRC effect committed.

3. HRC authorisation and durable outcomes#

An operation has separate stages: queued, authorised for evaluation, durably committed, and acknowledged. A fresh HyperNet check is required at the effect boundary, not only at session establishment.

1. Decode bounded input, authenticate the enrolled endpoint and validate the immutable action. Resolve an existing operation outcome before attempting a new effect.
2. When the queued action is eligible to run, request its fresh connection check. Do this outside the home commit critical section so a slow quorum does not block unrelated room controls.
3. Enter the home's serial effect order. Check that the evidence is still usable and bound to this action, connection and generation. Recheck current HRC endpoint, represented-account, grant, approval, room, agreement and epoch revisions. Known closure or restrictive state invalidates the check.
4. The guarded home transaction performs its final current-permission check at the serial authorisation point, then commits the event, outcome and required state atomically under the selected storage durability policy. No later HRC control can overtake an in-progress commit and still claim that it preceded the effect.
5. Publish and acknowledge only the durable outcome. Failure or uncertain completion follows Operation.Resolve; it does not trigger a fresh effect automatically.

The authorisation point is distinct from physical storage completion. An unknown HyperNet revocation after a valid check can race with this operation within the original bound. A slow storage operation can finish after that bound: do not relabel an existing durable event as rejected or claim that a timeout proved no effect. Retain its actual authorisation evidence and outcome, stop new work while storage health is uncertain, and resolve it after recovery. A proposed operation that has not crossed the authorisation point must obtain a new check if its proof expires.

This ordering does not confer a durable right to replay work after restart. Recovery may reveal an already committed result; new effects require fresh permission. If a storage failure makes the existence of a commit uncertain, report outcome unknown until the database can establish the result. The storage design must also prevent an old backup from recreating a still-retryable effect.

HRC control acknowledgement is precise: an acknowledged pause/revoke means every earlier operation has either reached its recorded outcome or is durably fenced under a defined recovery state, and no later operation can use the removed permission. The implemented guarded transaction fails closed when it cannot establish that boundary; a control cannot acknowledge precedence over an older unfenced commit that can still complete.

4. Directional privacy evidence#

Application streams already invoke Suite's relay connector. It connects to the relay, admits the transit voucher and establishes inner endpoint TLS before application handoff. Organisation and Independent are assurance profiles, not a direct-Internet switch. Independent assurance checks distinct declared operator keys and domains; it does not prove actual noncollusion. Companion connector · Route connector · Privacy guarantees

Implemented upstream contract: version-2 directional privacy with explicit evidence provenance. Saved profile labels remain insufficient. Outgoing metadata records the actual nested TLS path and configured route settings. A matching certified destination lookup contributes certifiedEndpointProfile; certifiedRelayProfile remains null without corresponding evidence. A retained voucher or a saved profile does not establish new currentness. Preparation path

A public endpoint (mode2) accepts inner TLS directly and its existing application proof does not bind a transit voucher. Consequently, incoming peer context alone cannot prove that a remote client used a relay. This does not change the supported Suite client's enforced outgoing route. Endpoint paths · Application proof and binding

A deployment requiring destination-verifiable relay arrival can use an attached endpoint (mode3), which has no public listener and authenticates its pinned relay attachment. Its exact-session receipt attests the endpoint mode, approved attachment, relay service and profile digest. The matching Suite release returns explicit unknown arrival privacy from version-2 accept without an optional query before payload handoff. HRC's fresh exact-action check supplies the current session evidence; acceptance and retained privacy never authorise an application effect. Absent or invalidated evidence stays unknown. This establishes arrival through the approved attachment, not origin anonymity, physical operator independence, current profile validity or the full path of a federated participant. A public endpoint requiring equivalent assurance still needs a separate supported relay-authenticated delivery contract; it cannot substitute an IP check or caller-supplied relay ID.

The ordinary HRC display describes this connection: selected minimum, verified transport, observed relay mode, supported profile provenance and evidence status. Any operator-separation declaration must be identified as a declaration with its actual evidence; the current interface sets physicalIndependenceVerified and profileCurrentnessAsserted to false. Unknown is a visible value. Do not infer whole-room or whole-federation privacy from one leg. A policy requiring unavailable evidence refuses the operation or room admission. Missing evidence never weakens a selected minimum.

Expose coarse properties and opaque evidence references in routine status. Detailed operator declarations are deliberate inspection data. Do not include addresses, local paths, raw profiles or private key material in ordinary HRC errors or diagnostics. A closed connection's previous description is historical, not an active privacy badge.

5. Bilateral federation evidence#

Keep the one-home, two-network profile. Each direction uses a source-side origin HRC service and a separately admitted destination gateway principal. The origin service attests its own enrolled endpoint and current transport observation; the destination gateway only carries the envelope. The home service owns room order, delegated grants and destination restrictions.

An agreement binds both network/incarnation identities, exact HRC service identities, gateways and signing keys, the accepted origin attestor, rooms, remote enrolment rules, moderator scope, history/retention, crypto/privacy mode, expiry and withdrawal. Both administrations accept the same immutable agreement bytes through authenticated local administration. Activation requires independent destination HyperNet admission; a signed agreement cannot create that admission. Trust in the origin attestor is explicit and limited to source-side facts.

The actor signs the immutable Action with its own enrolled HRC endpoint key. The origin attestor checks that signature and transport binding, obtains a fresh source check after receiving the home challenge, and signs the bounded assertion. The destination home verifies both signatures against separately accepted roles, the gateway's own current admission, challenge, agreement and current HRC rights. A gateway cannot become the original actor by changing the envelope kind.

Require exact comparisons of home, origin account/network/incarnation, room, action, endpoint/enrolment generation, binding digest, represented account, grant and agreement ID/revision/digest between the signed Action and the corresponding objects. The surrounding attestation cannot supply a different interpretation of an omitted signed identity or agreement field. A changed binding or agreement requires a new Action and any new exact approval; resolve the previous operation before deciding whether another effect is appropriate. The home challenge table is bounded and binds the authenticated requesting gateway; challenges are not issued to unauthenticated input. Denied, expired, duplicate and cancelled attempts consume bounded work. A new challenge may accompany an identical retry, but cannot change its immutable Action or extend the service-issued retry window.

Challenge consumption and the operation outcome must be atomic with the home commit. An existing result for the same actor and Action can be returned without recreating an effect; changing content under the same ID conflicts. Pending challenge state is discarded on restart, and old challenges are rejected. Committed outcomes survive according to the accepted deduplication policy. Foreign event copies never become a second send operation, and the first profile performs no onward forwarding.

The home bounds the full challenge round trip by at most five seconds on its own boot clock. It also applies the earliest valid source, agreement, destination and credential expiry, conservatively translated under the accepted clock-health model. Forwarding never starts a new source permission lifetime. If a safe expiry cannot be established, the request fails unavailable. The origin attestor is trusted for its source check; a signed foreign timestamp alone is insufficient. The federation runtime defines the signed schema and conservative clock conversion that preserve this inherited bound.

This profile inherits HyperNet's bounded unknown-revocation race. HRC-owned grants are instead checked at their receiving home. Agreement withdrawal immediately stops local new exchange and requests a durable home barrier; the UI distinguishes requested from acknowledged withdrawal. No disconnected network can claim that the other home has already stopped. Encrypted rooms block new sends until their required removal transition is validated.

6. Signature and representation#

The wire specification selects deterministic CBOR with COSE_Sign1 and a single explicit Ed25519 algorithm for HRC signed objects. It defines the exact assignments and role bindings. CBOR supplies a deterministic encoding profile; COSE supplies the standard signed structure. RFC 9864 assigns the fully specified Ed25519 COSE algorithm value -19, avoiding the deprecated polymorphic EdDSA identifier. RFC 8949 · RFC 9052 · RFC 9864

The profile requires definite lengths, shortest integer/length encoding, deterministic key order and rejection of duplicate keys, trailing data, malformed UTF-8 and unsupported types. Preserve exact signed payload bytes; never normalise text or decode/re-encode it into a different signature input. No floats, compression or arbitrary nested tags are needed in the first profile. Bounds apply to the outer envelope, every embedded object and their combined decode depth and size.

Specify protected algorithm, role/content type and key identifier; require an empty unprotected-header map and attached payload. Bind a distinct HRC protocol/version and object role in each payload. A key identifier is only a lookup hint into an already accepted role/key binding, never evidence of trust. Gateway, endpoint, origin-attestor and administrative signatures are not interchangeable. COSE signs the standard signature structure rather than an ad hoc concatenation of fields. The wire specification and maintained vectors define library use, strict decoding, exact field labels and extension rules. Interoperability claims require the corresponding implementation evidence.

HyperNet's existing signed objects remain opaque and retain their own verified representation. Do not rewrap them as HRC authority or reinterpret their action numbers. The HRC profile uses separate application keys and domains; it never borrows endpoint or authority private keys.

7. Boundaries, delivery and verification#

The companion extension and HRC runtime are implemented. Source-bound native checks cover the local conversation and interfaces, encrypted direct and private-group conversations, bilateral federation, and stopped same-schema upgrade with an uncertain committed send. Federation qualification uses two independently administered networks on one host; it does not establish independent host-failure recovery. These results retain their original artifact identities. The current pilot-load qualification is recorded in section 8. Federation extends the same operation and permission path under the selected runtime contract.

Meaningful regressions include: withdrawal before and after a fresh check; stale original context; changed action/session/nonce; expiry while queued; process restart; missing quorum or unhealthy clock; storage completion after the check deadline; known closure before authorisation; mode2 versus mode3 incoming evidence; wrong relay/TLS identity; selected-minimum downgrade; stale profile declarations; foreign-origin/key substitution; inherited expiry across forwarding; challenge replay; lost acknowledgement; and withdrawal during partition. Measure fresh-check cost and unaffected-client latency against the accepted stream allocation before claiming supported capacity.

The upstream boundary supplies fresh checks and typed context; HRC owns application permissions, atomic storage ordering, cross-host freshness and foreign actor authentication. The state specification, wire protocol, clock boundary, MLS runtime and text profile define the selected implementation contracts. The measured numerical qualification is limited to section 8. Changes to owner recovery authority or declared privacy/availability guarantees require an owner decision; ordinary implementation details can be resolved within these contracts.

8. Linux pilot qualification#

The native pilot passed on Ubuntu 26.04, kernel 7.0.0-42-generic, amd64 and GNU libc 2.43. Eight production Controllers and four supporting endpoints used twelve HRC accounts on two admitted client applications. Twelve receiving application streams, two authority connector sessions and two other authority routes fit the signed sixteen-slot relay allocation. Application admission allowed sixteen slots and the authority endpoint eight. Unused transition/federation reserves were not exercised concurrently with this load.

Five senders each offered one normal message per second: 150 offers over 30 seconds without hostile traffic and 225 over 45 seconds with the defined hostile workload. Every normal offer committed uniquely with a direct exchange sample. None was missed, refused, recovered in place of a direct sample, or duplicated. All eight Controllers ended current with no unresolved normal operation. Three hostile-phase normal commits completed during the 333 ms observation tail; pressure continued through that tail.

Message latency starts with the already encoded frame write on an established, authenticated stream and ends at complete receipt of its exact committed acknowledgement. It excludes setup, local queues/persistence, encoding, response decoding and UI work. Client completion includes those applicable client costs. The hostile result passes the selected one-second p95 profile; it does not pass the original 500 ms hostile comparison or promise every message below one second.

The hostile driver offered 453 flood operations and 91 queries, including the observation tail. It started 282 flood operations and 88 queries; 171 flood and three query offers were missed by their issuing clients. All started hostile work resolved. The report retains those missed offers instead of equating scheduled pressure with completed requests. A slow reader held sixteen requests for twelve seconds. Both moderation actions completed in 899/686 ms against a one-second limit. Recovery from the end of hostile work took 4401 ms against 30000 ms, with fresh remote markers and current state on all eight Controllers.

Recipient ignore, malformed/oversized frames, connection replacement and bounded agent-chain checks passed. The separate four-connection replacement check kept unaffected commits working; its maximum client completion was 6925 ms and is not part of the established-message latency cohort. HRC service RSS peaked at 34,676,736 bytes against 536,870,912 bytes, excluding HyperNet processes. Internal queue occupancy and complete link-byte amplification were not instrumented; maintained regressions verify the structural queue and admission bounds.

This is one bounded native qualification, not a capacity claim for larger networks, independent host failure, simultaneous federation load or a new platform. Federation has separate same-host, independently administered two-network evidence. Packaged offline CLI/GUI/TUI checks cover Ubuntu 24.04 and GNU libc 2.39; native load, full Wayland and screen-reader qualification are not established there. The package requires GNU libc 2.39 or later. These checks do not constitute an independent security assessment. Preserve current permissions and the documented retention, encryption, privacy and recovery boundaries when deploying.