Direct-dial resolve-and-call: shared internals for macula_request/macula_response, macula_streamer/ macula_stream_sink, and macula_feeder/macula_download.

Not a public API on its own — macula_request:start_link_direct/6,7,8, macula_response:advertise_direct/6,7, macula_stream_sink:start_link_direct/5,6, macula_streamer:advertise_direct/6,7, macula_download:start_link_direct/4,5, and macula_feeder:start_link_direct/5,6 are the entry points. Factored out because RPC, streaming, and content-download all need the same shape of resolve sequence (find_records -> verify -> read the record -> build a quic:// dial URL, retrying past DHT propagation lag throughout). Streaming and RPC share the IDENTICAL discovery mechanism — a procedure_advertisement does not distinguish RPC from streaming, only the eventual dial (call_station/7 vs call_stream_station/6) does — so publish_advertisement/4,5 is reused as-is by both providers, and call/6/call_stream/6 share the same resolve_dial_url/4 and "Trust model" below. Content has no publish step here at all — see "Content" further down.

The resolve side retries: a record just published on the provider's station has not necessarily replicated to the caller's station yet, and treating the first miss as failure would make every direct-dial call racy against DHT propagation lag. macula_station_cert_chain_SUITE (macula-station) proved this exact resolve+dial sequence works cross-station against the live fleet; this module is that sequence, lifted out of the test and made reusable.

Trust model

Two independent checks, both mandatory, cover what the QUIC/TLS layer cannot: (1) every candidate procedure_advertisement must carry a valid Ed25519 signature before its serving_station is trusted at all — otherwise any identity able to sign SOME record could name a real, legitimate station as the server for a procedure it has no authority over, and the station_endpoint check below would still pass (it only proves we reached the station we were told to reach, not that whoever told us so was authorized to); (2) the resolved station_endpoint must be signed by the station itself (verify_and_build/2, unchanged). The actual QUIC dial trusts NEITHER the TLS certificate (pin_tls_cert => false — a production station's TLS is terminated by an unrelated PKI, e.g. Let's Encrypt, so pinning the cert key can never succeed) NOR nothing (verify => none alone would trust whoever answers): trust is enforced at the application layer instead, via the cryptographically signed CONNECT/HELLO handshake (macula_peering_conn:bind_peer_identity/2) checked against the exact pubkey the signed DHT chain above resolved.

A third check is available but OPT-IN, via Opts (managed realms only — see macula_record:verify_advertisement_cert_chain/3): verify_cert_chain => {RealmCaPem, Org} additionally requires the advertisement's embedded X.509 service-cert chain to verify to RealmCaPem under Org (Slice 7c Direction B), proving the ADVERTISER — not just the station it names — is an org/realm- authorized identity. Without it, (1) above still rejects an unsigned or badly-signed advertisement, but not one signed by an unauthorized (if self-consistent) identity; unmanaged realms have no realm CA to check against, so this stays opt-in rather than mandatory.

Content

put_content/4 has no resolve step at all — unlike a GET, a PUT names its OWN target: the caller already knows (or is choosing) which station to seed, so it takes Station directly and resolves only that station's own station_endpoint (resolve_station_endpoint/2, the same machinery call/6 uses internally for serving_station).

get_content/3 resolves and fetches deliberately WITHOUT the cert-chain machinery above — content's threat model genuinely differs from RPC's. An RPC reply is opaque and unverifiable except by trusting whoever answered, so proving the ADVERTISER is authorized matters. Content is content-addressed: the fetched bytes are independently re-hashed against the MCID client-side (macula:verify_block_hash/2 for single-block, macula_manifest:verify/2 for chunked) regardless of which peer served them, so a rogue or unauthorized announcer can at most refuse to serve or waste a dial — it cannot make a caller accept content that does not hash to the MCID it asked for. What still matters, and is still mandatory, is (1)'s analogue for content_announcement: the signer must equal the announcer_node it claims (macula:decode_provider/1), so an attacker cannot at least misattribute who is claiming to serve what.