# ADR-034: Outgoing-Only X.509 and the Three Peer Roles *Ported from alknet ADR-034 (Outgoing-Only X.509 and the Three Peer Roles); re-targeted to alkhttp.* ## Status Accepted (resolves OQ-37) > **Port note (emphasis):** This port emphasizes **§4 — browsers are not > peers** — because that clause governs alkhttp's browser-facing surface > (the WebSocket path, alkhttp ADR-044/ADR-048). The X.509/TLS machinery > this ADR discusses (server cert verifiers, `TlsIdentity`, WebPKI > verification, fingerprint pinning) is **an alknet concern**: alkhttp is > transport-coupling-free and owns no TLS configuration or verifier > selection. The X.509-relevant sections (§2, §3, §5) are retained for > provenance and marked accordingly; what alkhttp consumes is the peer- > model closure of §4 and the three-role vocabulary of §1. ## Context OQ-37 framed the open question as: "the three credential types (Ed25519, X.509, bearer token) and how X.509 server identity fits the peer model." During resolution, it became clear that **three distinct remote roles** had been conflated under the single label "X.509 endpoint," and that the conflation was the actual source of the confusion — not the TLS mechanics, which alknet ADR-027 and alknet ADR-030 had already settled. The three roles are real and structurally different: 1. **Public X.509 endpoint** — a remote HTTPS or `alk/call`-over-TLS server reachable by domain name, authenticated by a CA-issued X.509 cert. The local node is a *client* of it. Examples: a third-party API (`vast.ai`, `api.openai.com`), a public hub that the local node dials over the open internet, an `alk/call` peer that has chosen to expose a domain + X.509 instead of (or in addition to) an Ed25519 raw key. The client authenticates to the server by **bearer token** (browsers and most HTTP clients cannot do TLS client-auth); the server authenticates to the client by **CA verification** (WebPKI), not by fingerprint pinning. 2. **Transport relay** — iroh's DERP-equivalent (`iroh-relay`). A connectivity-assistance node that forwards encrypted datagrams between peers who cannot directly connect (NAT traversal). It is *infrastructure*, not an application peer: it does not register operations, does not participate in the call protocol's peer graph, and has no `PeerEntry` / `PeerId` in the auth model. Nodes inherit it for free when the `iroh` feature is on; the relay's own identity (an Ed25519 `NodeId`) is iroh's concern, not the protocol stack's. *(Transport-relay mechanics are an alknet concern; alkhttp has no iroh dependency and no relay role — the relay is named here only to keep the three-role vocabulary intact.)* 3. **Hub / hosting node** — an application peer that acts as a hub in a hub-and-spoke (head/worker) topology. It is an ordinary `PeerEntry` that *happens* to also expose a public domain + X.509 (so browsers / external HTTPS clients can reach it) *and* an Ed25519 identity (so other nodes can reach it P2P via iroh or direct quinn). The git-hosting-relay-with-gossip-sync use case is this role: the hub is a full peer that additionally serves browsers. *(The hub's browser-facing surface is what alkhttp serves — the gateway endpoints and the WebSocket session.)* The pre-ADR-034 framing asked whether `PeerEntry` should be made **symmetric** — i.e., whether the local node should hold a `PeerEntry` for *every* remote it might dial, including pure-public-API servers it has no P2P relationship with. This ADR answers **no**: the asymmetry is correct and reflects a real difference in trust model. `PeerEntry` (and the `PeerId` it produces) is the model for **peers in the call-protocol peer graph** (alkcall ADR-024) — peers that get a stable logical identity, are addressable via `PeerRef::Specific`, and whose ops land in the peer-keyed overlay. A pure-client connection to a public HTTPS API is not that. This distinction matters because forcing a stable logical `peer_id` onto "the operator of `api.example.com`" is wrong: a public domain's operator can change hands, the cert can be reissued, and the local node has no stable logical identity to attach — only "domain X verified by CA Y today." That is a different trust model from "this Ed25519 key is `worker-a`, and key rotation updates the fingerprint but not the identity" (alkcall ADR-025). ## Decision ### 1. Name the three roles; stop using "relay" ambiguously The architecture documents use three distinct terms: | Role | Identity | Transport | Peer? | Example | |------|----------|-----------|--------------|---------| | **Public X.509 endpoint** | Domain + CA-issued X.509 | HTTPS / `alk/call`-over-TLS | No (client only, unless also role 3) | `api.alk.dev`, `vast.ai` | | **Transport relay** | iroh `NodeId` (Ed25519) | iroh's DERP-like protocol | No (infrastructure) | `relay.iroh.network` | | **Hub / hosting node** | Ed25519 raw key **and/or** X.509 | iroh / direct quinn / HTTPS | Yes (full `PeerEntry`) | git-hosting hub, head node | Existing specs that say "relay" when they mean "domain-hosted service" or "hub" are amended by reference to this table. alknet ADR-027's "domain- hosted services" and alkcall ADR-025's "X.509 cert" credential path refer to the **public X.509 endpoint** role and the **hub** role; iroh's transport relay is a separate, inherited component referenced only in the iroh transport path *(alknet concern)*. ### 2. Outgoing-only X.509 is not a `PeerEntry` on the client side *(TLS mechanics: alknet/alkcall concern; the peer-model rule: alkhttp-relevant)* When a `CallClient` (or the alkhttp `from_openapi` / `from_mcp` adapters) dials a remote that is a **public X.509 endpoint** and the local node has no P2P relationship with it (no `PeerEntry` for the remote): - The server is authenticated by **CA verification** (`rustls::WebPkiServerVerifier` with the platform root store or a configured CA bundle) *(the verifier itself is alknet/alkcall dial-layer machinery — alkhttp consumes its outcome, it does not build verifiers)*. There is no fingerprint to pin — pinning a `SHA256:` fingerprint against an external CA-issued cert is brittle (cert renewal changes the fingerprint) and is not the WebPKI trust model. The trigger for CA verification is **the absence of a `PeerEntry` for the remote combined with an X.509 transport**; the verifier selection rule is stated in full in §3 below. The `ConnectionCredentials.remote_identity: Option` field (alkcall ADR-012, extending alkcall ADR-022 §7) carries an expected fingerprint/cert when the caller has one to pin (`Some`); for a pure-client X.509 dial with no `PeerEntry`, `remote_identity` is `None` and the CA path applies. The `Option` is load-bearing — `None` is the public-X.509-endpoint state, not a missing field: an implementer must not default it to a placeholder, and must not treat `None` as "skip verification" (`None` + X.509 = CA verification; `None` + Ed25519 raw key = fail closed). (alkcall ADR-022 §7 specified `remote_identity` as "expected fingerprint or cert"; this ADR extends its semantics so that `remote_identity: None` + no `PeerEntry` + X.509 transport selects CA verification, and `remote_identity: None` + Ed25519 raw-key transport fails closed.) - The client authenticates to the server by **bearer token** (`ConnectionCredentials.auth_token`), carried in the call-protocol `auth_token` payload field (or the HTTP `Authorization` header for alkhttp's `from_openapi` / `from_mcp`). What the *server* does with that token depends on which kind of public X.509 endpoint it is: - **Third-party API** (`api.openai.com`, `vast.ai` — not an alknet node): the server applies its own auth scheme (its own API-key validation, its own ACL). The protocol's `PeerEntry` / `ApiKeyEntry` types do not apply on the far side; the client just carries the token in the shape the remote expects (an HTTP header, a call-protocol `auth_token` payload) and treats the remote's response as authoritative. - **Hub reached over its public X.509 path** (a role-3 hub dialed over the domain instead of P2P): the hub resolves the client's token via its own `PeerEntry.auth_token_hash` or `ApiKeyEntry` — the *server's* bookkeeping, not the client's. The client still holds no `PeerEntry` for the hub on its own side unless it also has a P2P trust relationship with that hub (in which case the §3 mixed-fingerprint path applies, not this one). - The client may still present its TLS client cert (Ed25519 raw public key, per alknet OQ-29) when one is configured; bearer token is the *authorization* credential, and TLS client-auth (when presented) is *additional* identity material the server may use. For a third-party API the cert is ignored; for a hub it may be extracted as a fingerprint. Presenting or omitting the client cert is the caller's choice via `ConnectionCredentials`; this ADR does not require disabling client-auth on this path. *(TLS client-cert presentation is dial-layer machinery — an alknet/alkcall concern, not alkhttp's.)* - The connection does **not** get a `PeerId` on the client side. It is not added to `PeerCompositeEnv` (alkcall ADR-024). There is no `PeerRef::Specific` routing to it. The connection is a live `CallConnection` (or, for alkhttp's reqwest-backed client host, an HTTP client session) the caller holds directly; ops discovered via the `from_call`-pattern import (alkcall ADR-028) or via alkhttp's `from_openapi` / `from_mcp` land in that connection's Layer 2 overlay (alkcall ADR-019) and are invoked through the connection handle, not through the peer-keyed routing layer. This is the **asymmetry** OQ-37 worried about, stated as a deliberate design property: `PeerEntry` is for peers in the call-protocol peer graph. Pure-client connections to public X.509 endpoints are not in that graph on the client side. The server may have a `PeerEntry` for *us* (resolving our bearer token, in the hub sub-case); we don't need one for *it*. ### 3. The hub case is already covered by ADR-030's mixed-fingerprint `PeerEntry` *(alknet/alkcall concern)* A **hub / hosting node** that is reachable both P2P (Ed25519 raw key via iroh or direct quinn) and via a public domain (X.509 for browsers) is a single `PeerEntry` with mixed fingerprints: ```rust PeerEntry { peer_id: "hub-a".into(), fingerprints: vec![ "ed25519:", // P2P path "SHA256:", // HTTPS / browser-facing path ], auth_token_hash: Some(""), scopes: vec![...], resources: {...}, ... } ``` *(The `PeerEntry` struct with mixed fingerprints is an alkcall type — alkcall ADR-025. Fingerprint normalization across quinn/iroh — alkcall ADR-025 §6 — is an alknet/alkcall dial-layer concern.)* When a node dials this hub P2P, the Ed25519 fingerprint matches; when it dials over the public X.509 path (e.g., because P2P connectivity failed), the X.509 fingerprint matches — both resolve to the same `peer_id` (`"hub-a"`). The X.509 path here uses **fingerprint pinning** (the `SHA256:` is in `PeerEntry`), *not* CA verification, because the local node has a prior P2P trust relationship with this specific hub and has recorded its cert's fingerprint. This is the one case where X.509 fingerprint pinning is correct: the peer is a known peer, not an arbitrary public API. The choice between **CA verification** (role 1) and **fingerprint pinning** (role 3, X.509 path) is driven by whether the local node has a `PeerEntry` for the remote — this is the authoritative verifier selection rule, referenced from §2: | Local has `PeerEntry` for remote? | Remote cert type | Client verifier | |----------------------------------|------------------|-----------------| | No (public X.509 endpoint) | X.509 | `WebPkiServerVerifier` (CA verification) | | No | Ed25519 raw key | fails closed (no CA to fall back to — raw-key remotes are always known peers; fingerprint IS identity) | | Yes (hub, Ed25519 path) | Ed25519 raw key | fingerprint match (`ed25519:`) | | Yes (hub, X.509 path) | X.509 | fingerprint match (`SHA256:`) | This is the key-type-aware verifier from alknet OQ-29, with the *peer-model* criterion made explicit: the verifier choice is determined by whether the remote is a known peer (`PeerEntry` present → pin) or an external server (`PeerEntry` absent → CA, or fail closed for raw keys). *(The verifier construction itself is dial-layer machinery — an alknet/alkcall concern; alkhttp's `from_openapi`/`from_mcp`/client host consume connections established under this rule but do not select verifiers.)* ### 4. Browsers connecting to a hub are not peers A browser reaching a hub over WebTransport (or HTTPS — and, per alkhttp ADR-044, over WebSocket) is served by the hub's HTTP handler — in the extracted crate tree, **alkhttp**. The browser authenticates by **bearer token** (HTTP `Authorization`), resolved by the hub's `IdentityProvider::resolve_from_token` against the hub's `PeerEntry.auth_token_hash` or `ApiKeyEntry`. The browser is **not a peer on the hub's side either** — it does not get a `PeerId`, does not enter `PeerCompositeEnv`, and its "ops" are HTTP routes / browser streams served by alkhttp, not entries in the call-protocol peer-keyed overlay. The hub's `PeerEntry` for the browser (if any) is about authorizing the bearer token, not about peer-graph membership. This keeps the peer graph populated only by full nodes (role 3 hubs and role-3-style spoke nodes), never by browsers or pure HTTP clients. > **Amendment (rationale added by alknet ADR-044 §5, ported to alkhttp > ADR-044):** The closure above is correct but states the conclusion > without the supporting argument. The distinction that makes it correct > is: **"peer" means an addressable node in the call-protocol peer > graph** — a stable `PeerId`, reachable via `PeerRef::Specific`, whose > ops land in `PeerCompositeEnv`, whose identity is stable across > reconnects. It does *not* mean "any endpoint that exchanges calls > during a live session." A browser is the second thing but not the > first, on three concrete grounds: (1) no stable cryptographic identity > of its own (it presents a bearer token the hub issued; nothing to > pin), (2) ephemeral (close the tab → connection dies → the > connection-local overlay dies with it; a `PeerEntry` keyed to a > browser would be dead within seconds), (3) not addressable from other > nodes (another node has no way to reach "the browser currently > connected to hub-A"; the hub holds it as a live `CallConnection` > handle, not a peer-graph entry). The connection-local Layer 2 overlay > (alkcall ADR-019; the inbound mirror of §2 above) is what gives the > browser bidirectional-call capability *without* peer-graph membership. > This rationale is transport-agnostic — it applies to WebSocket (the > browser path in alkhttp, alkhttp ADR-044) and to WebTransport > (an alknet transport; not in alkhttp scope — see alkhttp ADR-069) > equally. See alkhttp ADR-044 §5 for the full statement. ### 5. WebTransport relay-as-proxy is a transport-only feature, scoped separately *(alknet concern)* > **Port note:** WebTransport is **not in alkhttp scope at all** — per > alkhttp ADR-069 it was removed from this crate entirely (it is an > alknet concern). This section is retained for provenance of the > *auth-model* point (the proxy is transport-only and does not change > identity resolution), which remains true regardless of where the > proxy lives. A **WebTransport proxy** that terminates the browser's WebTransport connection and proxies encrypted traffic to a hub's P2P endpoint (avoiding the need for the hub itself to expose a public X.509 endpoint) is a real feature, especially for the browser-to-P2P-peer case. It is **not** load-bearing on the auth model resolved here: - The proxy does not change how identities resolve. The browser still authenticates by bearer token; the hub still resolves it via `PeerEntry.auth_token_hash`. The proxy is transport-only. - The fingerprint normalization committed in alkcall ADR-025 §6 (`ed25519:` for raw keys across quinn and iroh) was already designed to keep the proxied path clean: a proxied connection's Ed25519 identity is the same `ed25519:` whether the client connected directly or through the proxy. > **Amendment (wording only — the decision stands):** An earlier draft > of this section framed the relay-as-proxy as belonging to an > "h3/WebTransport deferral bucket" and "lands when `h3` / > WebTransport lands." That framing was a residual of the "two-way door > as deferral" anti-pattern (alkcall ADR-032 §"What this framework is > NOT") that alknet ADR-038 was later written to reject. alknet ADR-038 > has since been **superseded by alknet ADR-044**, which re-defers > `h3`/WebTransport as a genuine scope decision (the browser > bidirectional path uses WebSocket). In the alkhttp crate, the scope > question is closed differently: **WebTransport is removed from alkhttp > entirely** (alkhttp ADR-069) — there is no "revives later" posture in > this crate. The *auth-model* decision in this §5 (the proxy is > transport-only; it does not change identity resolution) is unchanged > by any of these ADRs. The *scope* question (which crate hosts the > proxy, if it is ever built) remains an alknet concern — the alknet > OQ-38 tracking is not carried into alkhttp. ### 6. On-chain / smart-contract peer discovery fits the OQ-36 adapter pattern *(alknet/alkcall concern)* The downstream use case — storing relay/repo info and org/user ACL on a smart-contract platform, with relays (hubs) syncing git repos via iroh's gossip protocol — is a **discovery and ACL-source** concern, not an auth-model concern. It does not change any of decisions 1–4: - The hubs are role-3 `PeerEntry` peers (mixed fingerprints, full peer- graph membership, gossip-synced). - The smart contract is a **source of `PeerEntry` records**. It maps cleanly onto the repo/adapter pattern (alknet ADR-033): a future on-chain peer-store adapter implementing `IdentityProvider` against a smart contract is additive, exactly like a SQLite peer store (alknet ADR-035). The auth model (`PeerEntry`, `PeerId`, `Identity`) is unchanged; only the *source* of the records changes. - The repo/ACL data on-chain is consumed by the hub's authorization layer (`AccessControl::check` against scopes/resources populated from the on-chain `PeerEntry`), not by the TLS / fingerprint path. Designing that adapter now would be premature — it is downstream of both the repo/adapter exploration (alknet OQ-36) and the git crate (alknet OQ-10). It is noted here only to confirm it does not reopen OQ-37. *(This is recorded for provenance; the peer-store adapters are alknet/alkcall assembly-layer components, not alkhttp surface.)* ## What this does NOT change - **`PeerEntry` struct shape** (alkcall ADR-025) — unchanged. Mixed fingerprints (Ed25519 + X.509) were already supported. - **`Identity` / `IdentityProvider` trait** — unchanged (vendored in the alkcall crate). The verifier choice is a `CallClient` / `from_openapi` / `from_mcp` dial-layer concern, not an `IdentityProvider` concern. - **`ConnectionCredentials` struct** — unchanged (alkcall ADR-012). `remote_identity` already carries the expected key type; this ADR specifies how the verifier is chosen from it (CA for unknown X.509 remotes, fingerprint match for known peers). - **`PeerCompositeEnv` / `PeerRef`** (alkcall ADR-024) — unchanged. Pure-client X.509 connections simply do not enter the peer-keyed overlay. - **`TlsIdentity`** (alknet ADR-027) — unchanged. The server-side X.509 / ACME / RawKey modes are unaffected; this ADR is about the *client-side* verifier choice for outgoing connections. *(And `TlsIdentity` itself is an alknet concern — not present in alkhttp.)* - **The no-env-vars invariant** — unaffected. The bearer token for the outgoing X.509 case still comes from `Capabilities` (alkcall ADR-010 secret-material flow), not env vars. ## Consequences **Positive:** - OQ-37 is resolved. The "make `PeerEntry` symmetric" instinct is rejected with a clear criterion: `PeerEntry` is for peers in the call-protocol peer graph; pure-client connections to public X.509 endpoints are not in that graph on the client side. - The three remote roles are named, so future specs and conversations can distinguish "public X.509 endpoint," "transport relay," and "hub / hosting node" instead of overloading "relay." - The client-side verifier choice has a single rule: known peer (`PeerEntry` present) → fingerprint pin; unknown X.509 remote (`PeerEntry` absent) → CA verification. This closes the `AcceptAnyServerCertVerifier` security hole for X.509 that alknet OQ-29 flagged, with the peer-model criterion made explicit. - The hub case (mixed Ed25519 + X.509 fingerprints, browser access via HTTPS and the browser transports) is confirmed to need no new types — alkcall ADR-025's `fingerprints: Vec` already covers it. - The relay-as-proxy and on-chain-discovery use cases are recorded with clear homes (the relay-as-proxy is a transport-only feature whose scope is an alknet concern — not tracked in alkhttp; the on-chain discovery follows the alknet OQ-36 adapter pattern) so they don't get lost and don't reopen the auth model. **Negative:** - The dial-layer client paths (alkcall's `CallClient`; alkhttp's `from_openapi` / `from_mcp` outbound adapters via the reqwest-backed client host) must respect the "is this remote a known `PeerEntry`?" distinction when a TLS client config is built for an outgoing connection. In alkhttp the credential injection point is the adapter layer (alkhttp ADR-014 secret-material flow): `ConnectionCredentials` — including `remote_identity` — are supplied by the consumer's assembly layer, and the verifier itself is built in the dial layer (alknet/alkcall), not in this crate. This is a small implementation cost and is local to connection establishment; it is not a structural change. - Operators must understand the distinction between "I have a `PeerEntry` for this remote (pin its fingerprint)" and "I'm calling a public API (trust the CA)." In practice this is intuitive (it's the difference between `~/.ssh/known_hosts` and a browser's CA trust store), but the docs must state it clearly, which this ADR and the spec amendments do. - Pure-client X.509 connections have no `PeerId` on the client side, so any future feature that wants to route to "the connection I opened to `api.alk.dev`" must hold the `CallConnection` handle directly rather than using `PeerRef::Specific`. This is the correct constraint — `PeerRef::Specific` is for known peers, not for arbitrary dials — but it is a constraint downstream code must respect. ## Assumptions 1. **A remote reachable by Ed25519 raw key is always a known peer.** Raw-key remotes have no CA; the fingerprint IS the trust anchor. An unknown Ed25519 remote cannot be verified at all (there is no CA to fall back to), so the connection fails closed. This means the "public X.509 endpoint" role is the *only* role where the local node dials a remote it has no `PeerEntry` for. This is correct and intended — it is the same model iroh uses. *(The iroh transport is an alknet concern; the fail-closed rule is stated here because it is a property of the credential model, not of any transport.)* 2. **Browsers never enter the peer-keyed overlay.** A browser is served by alkhttp (gateway routes and, per alkhttp ADR-044/ADR-048, the WebSocket session) and authenticates by bearer token. The hub may have a `PeerEntry` for the browser's token (to authorize it), but the browser is not a `PeerId`-bearing peer. This is the explicit closure of the "browser as peer" path — browsers are clients, not peers. **The rationale** (addressability vs. bidirectionality — a browser has no stable identity of its own, is ephemeral, and is not addressable from other nodes) is stated in alkhttp ADR-044 §5, which amends §4 above by reference. The closure applies transport- agnostically. 3. **X.509 fingerprint pinning is only for known hubs.** Pinning an X.509 fingerprint for an arbitrary public API is brittle (cert renewal) and is not done. The `PeerEntry.fingerprints` X.509 entry is for the hub case where the local node has a P2P trust relationship and wants to also recognize the hub's domain-facing cert. 4. **The on-chain / smart-contract discovery use case does not change the auth model.** It is a source of `PeerEntry` records, implemented as an additive `IdentityProvider` adapter (alknet ADR-033 / alknet OQ-36). The hub-and-gossip topology it implies is built from role-3 hubs, which this ADR confirms are ordinary `PeerEntry` peers. ## References - OQ-37 (resolved by this ADR) — the three auth types and how X.509 server identity fits the peer model - alknet [ADR-027](027-tls-identity-redesign-acme-rawkey-decoupling.md) — `TlsIdentity` (RawKey / X509 / Acme), the browser limitation (no RFC 7250), WebTransport requires X.509 *(ported to alkhttp — same file name in this directory; the TLS machinery itself is an alknet concern)* - alkcall ADR-024 — the peer-keyed overlay model that `PeerEntry` / `PeerId` feed into; pure-client connections are not in this graph - alkcall ADR-025 — `PeerEntry` with mixed fingerprints; fingerprint normalization (`ed25519:` across quinn/iroh); the `SHA256:` X.509 fingerprint format - alknet ADR-033 / alknet ADR-035 — the repo/adapter pattern that an on-chain `IdentityProvider` adapter follows and the concrete SQLite adapter shape (the on-chain adapter would follow the same trait + separate-crate pattern) *(alknet decisions, not ported to alkhttp)* - alkcall ADR-022 §7 — `CallCredentials` (now `ConnectionCredentials`, alkcall ADR-012) with `remote_identity`; alkcall ADR-022 specified "expected fingerprint or cert", this ADR §2 extends its semantics so that `remote_identity: None` + no `PeerEntry` + X.509 transport selects CA verification - alkcall ADR-019 — the Layer 2 per-connection overlay where ops discovered via the `from_call` pattern (alkcall ADR-028) or via alkhttp's `from_openapi` / `from_mcp` on a pure-client X.509 connection land - alknet OQ-29 (resolved) — key-type-aware server cert verification; this ADR adds the peer-model criterion (known peer vs. public X.509 endpoint) that selects the verifier - alknet OQ-10 (deferred) — git adapter scope; the on-chain / gossip-synced git-hosting hub use case in §6 is downstream of the git crate *(alknet OQ)* - alknet OQ-36 (resolved by alknet ADR-035) — concrete persistence adapter shapes; the on-chain `IdentityProvider` adapter in §6 follows the same repo/adapter pattern *(alknet OQ)* - alknet ADR-038 — **superseded by alknet ADR-044**; not ported to alkhttp. See alknet ADR-034 §5's amendment history and alkhttp ADR-069 (WebTransport removed from alkhttp scope). - alkhttp ADR-044 — the WebSocket browser path; §5 states the "browser is not a peer" rationale that amends this ADR's §4 - alkhttp ADR-048 — the WebSocket session shape; the browser bidirectional path this ADR's §4 governs - iroh transport relay (`iroh-relay`) — referenced to distinguish it from the hub role *(iroh docs; an alknet transport concern)* - alkcall crate docs — `CallClient`/`ConnectionCredentials` dial path, verifier selection by `PeerEntry` presence; see the alkcall crate's own documentation for the client-and-adapters spec ## Port notes - The call protocol core types are vendored in the **alkcall** crate (old alknet-core + alknet-call merged). All type-level references are re-cited to alkcall ADRs: peer-keyed overlay/`PeerCompositeEnv` is alkcall ADR-024, `PeerEntry`/fingerprint normalization is alkcall ADR-025, `CallClient`/adapter contract is alkcall ADR-022 (§7 credentials), `ConnectionCredentials` is alkcall ADR-012, Layer 2 registry layering is alkcall ADR-019, `from_call` as a manual free function is alkcall ADR-028. The alknet ADR numbers that originally carried these (ADR-029, ADR-030, ADR-017, ADR-024) are alknet numbers and do not coincide with alkcall or alkhttp numbers; each citation above names the owning crate explicitly. - `CallCredentials` → `ConnectionCredentials`: alkcall ADR-012 renamed the credential struct when it decoupled dial from call; the ported text uses the current name with the original alkcall ADR-022 §7 citation preserved. - `alknet/call` (the old ALPN string) → `alk/call` (alkcall ADR-004 `alk/` convention). Table and prose updated. - "alknet-http" → "alkhttp"; "alknet node"/"alknet peer" phrasing generalized to "node"/"peer" where the sentence is about the protocol model rather than the alknet binary. - §4 heading and prose originally said "over WebTransport"; the port adds "(or HTTPS — and, per alkhttp ADR-044, over WebSocket)" and attributes the served surface to alkhttp. WebTransport references are marked as alknet concerns; in alkhttp, WebTransport is out of scope entirely (alkhttp ADR-069), not deferred. - §2, §3, §5, and §6 are retained for provenance but annotated: TLS verifier selection, fingerprint pinning, the iroh transport relay, and the on-chain peer-store adapter are dial-layer/alknet concerns, not alkhttp surface. §4 is the load-bearing clause for this crate and is the emphasis of this port. - alknet OQ references (OQ-29, OQ-36, OQ-37, OQ-10, OQ-38) are alknet open-questions records, not ported into alkhttp's OQ file; they are cited textually as "alknet OQ-NN" (alkcall ADR-024 is cited for the peer-graph model rather than alknet OQ-37's original resolution context). - Reference links rewritten: `../../decisions/...` and `../../crates/...` relative links replaced per alkhttp docs conventions; links into the old call/core spec trees became textual "alkcall crate docs" references. alknet ADR-027 is linked as a sibling file because it is ported to alkhttp (same number and slug). - The original also cited `docs/research/alknet-http/phase-0-findings.md` (DH-2) and iroh reference docs; these are alknet research artifacts and are referenced textually only. - Original title preserved: "Outgoing-Only X.509 and the Three Peer Roles".