1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
//! Mediator connection and inbound dispatch, for both transports.
//!
//! The split below is the one that matters: the **connection** is shared and
//! the **protocol surfaces** are not. `service` builds one `DidCommTransport`
//! over the mediator socket and its inbound loop hands DIDComm frames to the
//! DIDComm router and TSP frames to [`tsp_inbound`] — one socket per DID
//! carrying either protocol (ADR 0005). So `service`, `readiness` and `auth`
//! are gated on `any(didcomm, tsp)`, while the DIDComm protocol machinery
//! (routing, handlers, drain windows, the mediator registry, protocol
//! management) stays `didcomm`-only and is simply absent from a TSP-only build.
/// Durable Trust Task pushes to peers, over `vti_common::trust_task_push`.
/// Startup self-readiness gate for the mediator connection. Transport-neutral:
/// the mediator authenticates us by resolving our DID whichever protocol we
/// then speak on the socket.
/// Per-sender arrival ordering for the inbound loop: a relationship-control
/// frame is a barrier for its sender's later traffic (Keyring VTI-43).
/// Delivery-layer construction + protocol-routed inbound loop (D2 P2a).
/// Local replacements for the `affinidi-messaging-didcomm-service` types the
/// DIDComm handlers depend on (D2 P2a cut-over). See [`shim`].