docs(arch): endpoint types and entry points (ADR-086) — resolves OQ-62

Name the three-endpoint-type model (web/native/iroh) and the
entry-point vs. endpoint ALPN distinction. This untangles the
hub/endpoint/ALPN-config confusion that OQ-62 hinted at:

- A hub composes a SUBSET of three endpoint types (web, native, iroh),
  each with its own identity model, auth model, and transport(s). A
  full hub runs all three; a minimal hub runs iroh alone (no public
  IP required). The first real use case is web + native. Corrects the
  hub README's 'must support TCP+TLS and QUIC' framing.

- ALPNs split into entry points (accepted without identity — h2,
  http/1.1, future alknet/register) and endpoints (identity required
  before dispatch — alknet/channels, alknet/call, alknet/ssh). This
  resolves OQ-62: split ALPN lists by endpoint type (Option B), because
  each endpoint type serves a different client class with different
  negotiable ALPNs. The assembly-layer wiring pattern is now guessable.

- Foundational handlers are two categories, not one: channels
  data-channel ALPNs (tunnel, socks5, fs, sftp — gated by channels,
  not in any TLS ALPN list) vs. SSH (an endpoint ALPN that wraps
  channels inside it, RFC 7250 keys, legacy compat, comes later).

Files OQ-65 (WebSocket carrying channels — the browser story update)
filed as a one-way-door question, open. ADR-048 is not superseded;
OQ-65 may extend it. The web config advertises alknet/channels by
default so the hub is ready if OQ-65 resolves to 'WebSocket carries
channels.'

docs/architecture/questions/062-alpn-list-sharing-two-config-hub.md

@@ -7,7 +7,7 @@
   lists); `docs/architecture/crates/core/endpoint.md` (the ALPN section
   previously stated "both connection sources advertise the same set of
   ALPNs," which is stale under the two-config hub model).
-- **Status**: open
+- **Status**: resolved
 - **Door type**: one-way (the ALPN list each `TlsServerConfig` advertises
   is baked into the `rustls::ServerConfig` at construction; changing it
   after the hub is deployed is a config+restart, but the *pattern* —
@@ -16,39 +16,51 @@
 - **Priority**: high (the hub is the first two-config consumer; its
   wiring sets the pattern, and an implementer cannot write the hub's
   assembly code without this decided)
-- **Resolution**: Not yet decided. The two plausible options:
+- **Resolution**: **Split list, by endpoint type.** Each
+  `TlsServerConfig` advertises only the ALPNs its endpoint type's
+  client class can negotiate. The hub composes a subset of three
+  endpoint types (web, native, iroh), each with its own identity model,
+  auth model, and transport(s). The assembly layer filters
+  `registry.alpn_strings()` per `TlsServerConfig` by endpoint type:
 
-  **Option A — same list (union) to both configs.** Both
-  `TlsServerConfig`s receive `registry.alpn_strings()` verbatim. The
-  raw-key QUIC listener advertises `h2`/`http/1.1` (browsers can't
-  connect to a raw-key listener anyway, so the advertisement is
-  harmless dead negotiation). The X.509 TCP+TLS listener advertises
-  `alknet/call` (a native client connecting over TCP+TLS with an X.509
-  client cert can use it). Simplest wiring; no split logic; every
-  transport can serve every ALPN.
+  - **raw-key config (native endpoint)**: `alknet/channels`,
+    `alknet/call`, `alknet/ssh` (future) — the native ALPNs. No
+    `h2`/`http/1.1` (browsers cannot connect to a raw-key listener;
+    native clients do not negotiate HTTP ALPNs).
+  - **X.509/ACME config (web endpoint)**: `h2`, `http/1.1`,
+    `alknet/channels` (for WebSocket-carrying-channels, per OQ-65),
+    `acme-tls/1` (appended automatically). No `alknet/call` as a
+    top-level ALPN unless the deployment explicitly serves
+    call-over-TCP on the web endpoint.
+  - **iroh builder (iroh endpoint)**: `alknet/channels`,
+    `alknet/call` — iroh uses raw keys only; native ALPNs.
 
-  **Option B — split list, transport-appropriate.** The raw-key config
-  gets the native ALPNs (`alknet/call`, `alknet/channels`,
-  `alknet/tty`); the X.509/ACME config gets the union including
-  `h2`/`http/1.1` (browser ALPNs that only make sense over TCP+TLS with
-  a domain cert). The assembly layer filters `registry.alpn_strings()`
-  by which transports can serve each ALPN. More logic; cleaner
-  advertisement (no browser ALPNs on a raw-key listener).
+  The rationale: each endpoint type serves a different client class.
+  Advertising ALPNs the client class cannot negotiate (e.g., `h2` on a
+  raw-key listener) is harmless but misleading — it implies the
+  listener serves a client class it cannot. The split makes the
+  advertisement honest and the assembly-layer wiring pattern guessable.
 
-  The question is whether the "harmless dead negotiation" in Option A
-  is acceptable or whether the cleaner advertisement in Option B is
-  worth the split logic. This needs a decision before the hub's
-  assembly code is written — it is not guessable from the existing
-  specs, and guessing produces a wiring shape that downstream consumers
-  copy.
+  The naming that makes this answerable is the **entry-point vs.
+  endpoint** distinction (ADR-086 §2): entry-point ALPNs (`h2`,
+  `http/1.1`, future `alknet/register`) are accepted without
+  established peer identity (per-request auth); endpoint ALPNs
+  (`alknet/channels`, `alknet/call`, `alknet/ssh`) require identity
+  resolution. The web config advertises entry-point ALPNs (for
+  registration, browsers) + `alknet/channels` (for
+  WebSocket-channels); the native config advertises endpoint ALPNs
+  (for native clients); iroh advertises endpoint ALPNs (for p2p
+  peers).
 
-  Note: this is distinct from the *iroh* path. Iroh takes its ALPN list
-  from `iroh::Endpoint::builder().alpns()` at construction, set by the
-  assembly layer from `registry.alpn_strings()`. Iroh uses raw keys
-  only, so it gets the native ALPN set regardless of which option is
-  chosen for the quinn/TCP+TLS pair.
-- **Cross-references**: ADR-082 (`TlsServerConfig::new` takes
-  `alpns: &[Vec<u8>]` — the caller decides), ADR-083 (the assembly
-  layer builds transports; ALPN-list construction is its job),
-  OQ-64 (client-side TLS helper — related but orthogonal; this OQ is
-  server-side advertisement)
+  See [ADR-086](../decisions/086-endpoint-types-and-entry-points.md)
+  for the full decision, including the three-endpoint-type model, the
+  hub-shape table (full / web+native / native+iroh / minimal), and the
+  foundational-handler categorization (channels data-channel ALPNs vs.
+  SSH as an endpoint ALPN that wraps channels).
+- **Cross-references**: [ADR-086](../decisions/086-endpoint-types-and-entry-points.md)
+  (the decision), ADR-082 (`TlsServerConfig::new` takes
+  `alpns: &[Vec<u8>]` — the caller decides; this OQ specified how),
+  ADR-083 (the assembly layer builds transports; ALPN-list construction
+  is its job), OQ-65 (WebSocket carrying channels — why the web config
+  advertises `alknet/channels`), OQ-64 (client-side TLS helper —
+  related but orthogonal; this OQ is server-side advertisement)

docs/architecture/questions/065-websocket-carrying-channels.md

@@ -0,0 +1,76 @@
+# OQ-65: Should WebSocket Carry the Channels Protocol (Not Just the Call Protocol)?
+
+- **Origin**: `docs/architecture/crates/http/websocket.md` (ADR-048
+  specifies WebSocket carries the native call-protocol session — the
+  `EventEnvelope` wire format over a WebSocket text/binary frame
+  stream); `docs/architecture/decisions/086-endpoint-types-and-entry-points.md`
+  §3 (the web config advertises `alknet/channels` for the
+  WebSocket-carrying-channels path — a path ADR-048 does not specify).
+- **Status**: open
+- **Door type**: one-way (this supersedes or extends ADR-048's
+  "WebSocket carries the native call-protocol session" decision. If
+  WebSocket carries channels, a browser opens one WebSocket and gets
+  the full channels substrate — `channel/open`, data-channel ALPNs,
+  the relay path through the hub — instead of only the call-protocol
+  session. This is a browser-wire-format one-way door: once browsers
+  depend on the channels-over-WebSocket framing, changing it is a
+  breaking change for every browser client.)
+- **Priority**: medium (the browser story works without this —
+  ADR-048's call-protocol-only WebSocket is functional — but
+  channels-over-WebSocket makes the browser a first-class channels
+  participant, which simplifies the hub relay and the browser's access
+  to data-channel ALPNs like TTY and tunnels. The question is whether
+  the simplification is worth the one-way-door commitment now, or
+  whether the call-protocol-only path suffices until a concrete
+  browser-needs-a-data-channel use case arrives.)
+- **Resolution**: Not yet decided. The two options:
+
+  **Option A — WebSocket carries call only (ADR-048 unchanged).** The
+  browser opens a WebSocket and gets a call-protocol session
+  (`EventEnvelope` over WebSocket frames). Data-channel ALPNs (TTY,
+  tunnels) are not accessible from the browser — the browser can invoke
+  call operations but cannot open a `alknet/tty` channel. A browser
+  needing a TTY would use a separate WebSocket per session, each
+  carrying the TTY wire format directly (not via `channel/open`).
+  Simpler; the browser is a call-protocol client, not a channels
+  client.
+
+  **Option B — WebSocket carries channels (extends/supersedes
+  ADR-048).** The browser opens a WebSocket and gets a channels
+  connection — the 9-byte chunk format (ADR-071) over WebSocket binary
+  frames, with channel 0 as `alknet/call` and data channels opened via
+  `channel/open`. The browser is a full channels participant: it can
+  open TTY channels, tunnels, etc. through the same WebSocket. The
+  hub relay (ADR-079) works unchanged — the browser leg is a channels
+  connection, same as a native leg. This is the "browser as
+  channels client" path.
+
+  The trade-off: Option B commits to the channels-over-WebSocket
+  framing as a browser wire format (one-way door), but makes the
+  browser a first-class channels participant and simplifies the hub
+  (one relay model, not two). Option A keeps the browser simpler but
+  means the browser cannot use data-channel ALPNs over the same
+  connection — each data-channel ALPN needs its own WebSocket and its
+  own browser-side implementation.
+
+  This question is decision-ready when the first browser-needs-a-
+  data-channel use case arrives (e.g., a browser-based terminal that
+  needs `alknet/tty` over the hub). Until then, ADR-048's
+  call-protocol-only path is the implemented browser path, and the
+  web config advertises `alknet/channels` by default (per ADR-086 §3,
+  so the hub is ready for Option B if chosen).
+
+  Note: this is distinct from the WebTransport path (deferred per
+  ADR-044). WebTransport, when revived, would carry channels natively
+  (a WT bidi stream = a channels connection). WebSocket-carrying-
+  channels is the WebSocket equivalent — same substrate, different
+  transport. If Option B is chosen, the WebSocket-channels framing
+  and the WebTransport-channels framing share the channels wire
+  format (ADR-071); only the transport differs.
+- **Cross-references**: ADR-048 (WebSocket carries the native
+  call-protocol session — the current decision this OQ may supersede
+  or extend), ADR-071 (channels wire format — the 9-byte chunk format
+  that would ride over WebSocket binary frames), ADR-079 (hub relay —
+  unchanged if the browser is a channels client), ADR-086 §3 (the web
+  config advertises `alknet/channels` for this path), ADR-044
+  (WebTransport deferred; WebSocket is the v1 browser path)