Who owns `link_bind` — the transport does, silently, and `DevicePeer.setLinkId` is dead code

[liversedge]

Raised by PinPointStudio in the preview handover, 28 August 2026, §2.3 — the ⚠ they left behind after removing a call that could only ever fail.

The two halves of link_bind, and nobody owns it on purpose

ENC 2.1 has a dialler mint a 16-byte link id and write a link_bind as the first frame on each bulk channel. This application does that twice over, in two places, one of which is switched off:

PpcpTransport.openChannel(_:) (Sources/Platform/Network/PpcpTransport.swift:549)	Mints the link id and writes the 2.1d frame itself. This is the one that runs.
DevicePeer.setLinkId / .openChannel (Packages/Core/…/Ppcp/DevicePeer.swift:597, :605)	The engine's half. setLinkId is called nowhere in the application — its only caller anywhere is SessionBundleTests.swift:387.

⛔ So the engine holds no link id, and ppcp_peer_open_channel() refuses on exactly that (ppcp_peer.c:899). HostLinkSession.openPreviewChannel called it anyway; the refusal was surfaced as no_preview_channel, and src:camera:wide was refused on every connect while its third channel sat up and working. Removed in 2f604b1.

Why it is still open after the removal

The removal made preview work. It did not decide anything: the answer today is "the transport owns it, silently", discoverable only by reading the comment at HostLinkSession.swift:668 or by losing two days.

⚠ DevicePeer.setLinkId is now dead code that looks live. LinkBinder's own doc comment still says "the dialler half is DevicePeer.setLinkId and .openChannel" — which is the exact reading that produced the defect.

What is being asked

Decide which layer owns link_bind, and make the tree say so:

• The transport owns it — then delete DevicePeer.setLinkId and DevicePeer.openChannel, or mark them unused-by-design, and correct LinkBinder's comment.
• The engine owns it — then call setLinkId with the transport's minted id and let peer.openChannel write the frame.

⚠ Not a preview issue. It governs every bulk channel, and the next one added will meet the same trap.

Exit criterion

One owner, named at the site, with no reachable API for the other. A reader who has not read this issue cannot make the mistake 2f604b1 fixed.

[liversedge]

Verified still open, 31 August — the trap is intact in the tree

Three days on from 2f604b1, nothing here has been decided and the exact reading that produced the defect is still on disk:

Packages/Core/Sources/CaptureCore/Ppcp/LinkBinder.swift:33
    /// solve. The dialler half is `DevicePeer.setLinkId` and `.openChannel`.

Packages/Core/Sources/CaptureCore/Ppcp/DevicePeer.swift:622
    public func setLinkId(_ linkId: PpcpLinkId) throws {

setLinkId is still public, still reachable, and its only caller anywhere is still SessionBundleTests.swift:387. ⚠ Two notes now point at the problem — HostLinkSession.swift:179 and :760 — but a note is not what the exit criterion asks for. A reader who has not read this issue can still make the mistake, and LinkBinder's own doc comment will actively lead them into it.

⛔ A third bulk channel was added since this was filed — the wired path's, via PpcpTransport.openChannel (adbb70c, 8201ec8). It went through the transport and worked, which is the good outcome; it is also this issue's warning arriving on schedule — "it governs every bulk channel, and the next one added will meet the same trap."

Exit criterion unchanged: one owner, named at the site, with no reachable API for the other.

[liversedge]

Unchanged in the code, but link_bind is now visible on the wire

DevicePeer.setLinkId still has no caller — the only two mentions of it in the tree are the comments saying so (HostLinkSession.swift:242, :960). The transport still owns link_bind silently.

What has changed is that it is no longer silent in the diagnostics. 8201ec8 instruments the per-channel sequence, and a run reads:

channel bulk    dialled TLS 1.2
channel bulk    link_bind sent
channel control dialled TLS 1.2
channel control link_bind sent

with a link_bind FAILED line for the other outcome. So the question this issue asks — who owns link_bind — can now be answered from a phone's own log rather than by reading the transport, and a bind that does not happen is findable. The design decision it asks for is untouched.